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EXECUTIVE  SUMMARY 


The  Traffic  Information  Service  fTIS)  is  a  Mode  Select  (Mode  S)  Data  Link  service  that  delivers 
automatic  traffic  advisories  to  pilots.  The  goal  of  TIS  is  to  provide  an  affordable  means  to  assist 
the  general  aviation  (GA)  pilot  in  visual  acquisition  of  surrounding  air  traffic.  The  service  is 
automated  and  functions  independently  from  air  traffic  controllers.  The  alert  messages  are 
relayed  to  the  client  aircraft  via  the  built-in  data  link  capability.  The  system  does  not  require  any 
changes  in  the  equipage  of  intruder  aircraft. 

The  introduction  of  TIS  (into  the  Mode  S  baseline)  added  a  total  of  380  new  requirements  to  be 
verified.  Verification  of  these  TIS  requirements  was  split  into  two  major  test  categories, 
Developmental  Test  and  Evaluation  (DT&E)  and  Operational  Test  and  Evaluation  (OT&E). 
Testing  of  these  new  requirements  was  conducted  using  three  methods:  Software  Code 
Inspections,  Test  Scenarios  (simulated  targets),  and  Live  Aircraft  Flights.  The  pre-existing 
Mode  S  functionality  was  verified  using  the  standard  Mode  S  Release  Qualification  Test  (RQT). 
Testing  of  the  Data  Link  channel  capacity  was  accomplished  via  a  demonstration  during  the  live 
flights.  Central  Processing  Unit  (CPU)  utilization  tests  were  conducted  to  determine  a 
recommendation  for  setting  the  "TIS  Maximum  Aircraft  Supported"  Site  Adaptable  Parameter 
(SAP)  value. 

The  formal  combined  DT&E/OT&E  of  the  Traffic  Information  Service  (TIS)  software  was 
conducted  at  the  Federal  Aviation  Administration  (FAA)  William  J.  Hughes  Technical  Center  by 
the  Surveillance  Branch,  ACT-310,  from  July  14,  1997,  through  September  16,  1997. 

Overall  results  of  the  formal  testing  are  very  good.  All  of  the  Software  Code  Inspection  test 
cases  were  successfully  verified.  The  scenario  testing  revealed  no  major  problems,  and  only 
three  minor,  low  frequency  problems  were  identified;  (1)  self-alerts,  (2)  invalid  altitude,  and  (3) 
a  tracking  anomaly.  The  first  two  minor  problems  are  due  to  inaccuracies  in  the  Mode  S 
surveillance  data,  and  the  third  (while  within  specification)  could  be  misleading  to  a  pilot.  The 
live  flight  tests  revealed  the  same  three  minor  anomalies,  with  no  other  problems.  The 
regression  testing  and  RQT  were  successfully  completed.  The  CPU  Utilization  testing  indicated 
that  the  maximum  client  SAP  should  be  set  to  100.  The  Data  Link  Bandwidth  test  demonstrated 
ample  channel  capacity  while  running  in  TIS  mode. 

In  conclusion,  after  successful  completion  of  formal  DT&E/OT&E  testing,  in-depth  data 
analysis,  and  evaluation,  the  TIS  software  has  been  found  to  function  according  to  specifications 
for  all  measured  parameters.  The  addition  of  the  TIS  data  link  services  appear  to  have  no 
adverse  effect  on  the  Mode  S  sensor  operation  or  performance.  The  Mode  S  data  link 
capabilities  function  properly  providing  TIS  alerts  and  status  messages  in  a  timely  manner. 

Based  on  the  above  findings,  ACT-310  recommends  that  TIS  be  conditionally  approved  for 
national  deployment  contingent  upon  the  following: 

1 .  The  Aeronautical  Information  Manual  (AIM)  and  all  other  applicable  user  documentation 
be  revised  to  thoroughly  document  the  known  problems  (self-alert,  invalid  altitude,  and 
tracking  anomalies). 

2.  This  version  of  TIS  is  only  fielded  in  terminal  sensor  configurations. 
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1.  INTRODUCTION. 


The  formal  Developmental  Test  and  Evaluation  (DT&E)  and  Operational  Test  and  Evaluation 
(OT&E)  of  the  Traffic  Information  Service  (TIS)  software  was  conducted  at  the  Federal  Aviation 
Administration  (FAA)  William  J.  Hughes  Technical  Center  by  the  Surveillance  Branch,  ACT- 
310,  from  July  14,  1997,  through  September  16,  1997.  The  following  sections  of  this  document 
will  serve  as  the  Final  Test  Report  for  that  test  effort. 


1.1  PURPOSE. 


The  primary  purpose  of  this  report  is  to  provide  the  detailed  analysis,  results,  the  final 
conclusions,  and  recommendations  drawn  from  the  DT&E  and  the  OT&E  of  the  TIS  data  link 
service  for  the  Mode  Select  (Mode  S)  beacon  radar  system. 


1.2  SCOPE. 


This  report  contains  an  evaluation  of  the  performance  of  the  TIS  data  link  function,  along  with 
an  assessment  of  impact  to  the  current  system  operation.  The  test  was  a  technical  evaluation  and 
a  verification  of  operational  specifications.  Included  within  this  report  is  a  Test  Verification 
Requirements  Traceability  Matrix  (TVRTM)  which  identifies  all  the  requirements  that  were 
verified,  including  a  reference  to  the  test  phase  and  report  paragraph  number  in  which  that 
verification  was  accomplished.  In  areas  where  TIS  performed  at  less  than  the  expected  levels 
there  was  a  detailed  analysis  conducted  to  determine  the  cause  for  the  deficiency. 

Additional  test  events,  not  defined  in  the  test  plan  (at  the  request  of  Massachusetts  Institute  of 
Technology  Lincoln  Labs  (MITLL)),  were  conducted  and  are  reported  here.  A  Mode  S  Data 
Link  channel  capacity  (bandwidth)  Demonstration  was  conducted  to  show  that  TIS  did  not 
significantly  impact  the  Mode  S  data  link  channel.  Also,  “Central  Processor  Unit  (CPU) 
Utilization  Tests”  were  conducted  to  determine  a  recommendation  for  setting  the  “TIS  Maximum 
Aircraft  Supported”  Site  Adaptable  Parameter  (SAP)  value. 

The  avionics  portion  of  the  TIS  system,  which  includes  the  Mode  S  Transponders,  Airborne  Data 
Link  Processor  (ADLP)  and  TIS  displays  were  not  evaluated  as  part  of  this  test  and  are  not 
reported  on  here.  They  were  merely  used  as  a  test  tool  to  collect  data  from  (uplink  messages), 
and  send  data  to  (downlink  messages)  the  Mode  S  sensor.  Previous  testing  of  the  ADLP  and  TIS 
displays  is  documented  in  the  Mode  S  Data  Link  Applications,  Field  Demonstration  Operational 
Test  and  Evaluation  Final  Report,  September  27,  1996,  and  A  Field  Evaluation  of  Data  Link 
Flight  Information  Services  for  General  Aviation  Pilots,  February  1997. 
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2.  REFERENCE  DOCUMENTS. 

This  section  contains  a  list  of  all  reference  documents  used  in  the  development  of  this  test  report. 

1.  Appendix  XIII  of  Mode  Select  Beacon  System  Sensor  Specification,  FAA-E-  2716,  Traffic 
Information  Service  (TIS)  Specification,  Terminal  Sensor  Configuration,  Revision  3.1, 
October  8,  1996 

2.  Requirements  Document  for  the  Traffic  Information  System  (Rev.2. 1),  April  25,  1997 

3.  Minimum  Operational  Performance  Standards  (MOPS)  for  Traffic  Information  Service  (TIS) 
Data  Link  Communications,  April  2,  1997 

4.  Software  Detailed  Design  Document  for  the  Traffic  Information  System  (Rev.2),  June  23, 
1997 

5.  Mode  Select  Beacon  System  (Mode  S)  Traffic  Information  Service  (TIS)  Developmental 
Test  and  Evaluation  (DT&E)  and  Operational  Test  and  Evaluation  (OT&E)  System  Test 
Plan,  July  1997  (Final) 

6.  Mode  Select  Beacon  System  (Mode  S)  Traffic  Information  Service  (TIS)  Developmental 
Test  and  Evaluation  (DT&E)  and  Operational  Test  and  Evaluation  (OT&E)  Code  Inspection 
Test  Procedure,  July  1997  (Draft) 

7.  Mode  Select  Beacon  System  (Mode  S)  Traffic  Information  Service  (TIS)  Developmental 
Test  and  Evaluation  (DT&E)  and  Operational  Test  and  Evaluation  (OT&E)  Test  Procedure 
for  Scenario  Data  Collection,  July  1997  (Final) 

8.  Mode  Select  Beacon  System  (Mode  S)  Traffic  Information  Service  (TIS)  Developmental 
Test  and  Evaluation  (DT&E)  and  Operational  Test  and  Evaluation  (OT&E)  Test  Procedure 
for  Live  Flight  Data  Collection,  July  1997  (Final) 

9.  Traffic  Information  Service  (TIS)  Developmental  /  Operational  Test  and  Evaluation  (DT&E 
and  OT&E)  Quick  Look  Report,  October  6,  1997 

10.  Aeronautical  Information  Manual  (AIM),  Official  Guide  to  Basic  Flight  Information  and 
ATC  Procedures 

11.  Federal  Aviation  Administration  (FAA)  National  Airspace  System  (NAS)  Test  and 
Evaluation  Policy  and  Guidance,  July  18,  1997 

12.  Lincoln  Laboratory  Flight  Test  Results  for  Traffic  Information  Service  (TIS)  Operational 
Test  And  Evaluation  Report  #  "42PM-Data-Link-0012"  dated  September  10,  1997 

13.  Mode  S  Data  Link  Applications,  Traffic  Information  Service  (TIS)  Graphical  Weather 
Service  (GWS)  Text  Weather  Service  (TWS),  Field  Demonstration  Operational  Test  and 
Evaluation  Final  Report,  September  27,  1996 
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14.  A  Field  Evaluation  of  Data  Link  Flight  Information  Services  for  General  Aviation  Pilots, 
DOT/FAA/CT-97/3,  February  1997. 
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3.  SYSTEM  DESCRIPTION. 


The  following  sections  briefly  summarize  the  system  mission  and  functions,  test  configuration, 
and  NAS  interfaces. 

3  1  MISSION  REVIEW. 

A  primary  flight  task  for  all  pilots  is  to  maintain  awareness  of  nearby  air  traffic  by  maintaining  a 
constant  visual  scan  (whenever  meteorological  conditions  permit).  If  traffic  is  sighted,  the  pilot 
must  first  assess  the  threat  posed  by  the  intruder  aircraft  then,  if  necessary,  maneuver  to  avoid  the 
other  aircraft.  This  strategy  for  collision  avoidance  is  termed  "see-and-avoid."  The  effectiveness 
of  see-and-avoid  depends  on  the  ability  of  the  pilot  to  visually  acquire  the  intruder  aircraft  early 
enough  in  the  encounter  to  allow  for  threat  assessment  and  avoidance. 

The  TIS  data  link  function  is  intended  to  improve  the  safety  and  efficiency  of  "see-and-avoid" 
flight  by  providing  automatic  display  to  the  pilot  of  nearby  traffic  and  warnings  of  any 
potentially  threatening  conditions.  The  source  of  TIS  information  is  the  file  of  aircraft  tracks 
maintained  by  the  ground  Mode  S  sensor  providing  coverage  for  a  region  of  airspace.  A  diagram 
of  the  functional  elements  of  TIS  is  shown  in  figure  3.1-1  below. 


FIGURE  3.1-1.  FUNCTIONAL  ELEMENTS  OF  TIS 
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While  TIS  can  provide  traffic  information  alerts  to  only  those  Mode  S-equipped  aircraft  under 
surveillance  track,  TIS  has  knowledge  of  all  Air  Traffic  Radar  Beacon  System  (ATCRBS) 
aircraft  in  coverage  (and,  potentially,  of  nontransponder-equipped  aircraft  when  a  primary  radar's 
coverage  is  integrated  with  the  Mode  S  sensor).  TIS  generates  alerts  for  any  traffic  aircraft  in 
Mode  S  coverage  that  carry  a  transponder  (ATCRBS  or  Mode  S).  By  utilizing  the  surveillance 
database  maintained  by  Mode  S  ground  interrogators  and  the  data  link,  TIS  can  provide  airborne 
traffic  alerting  with  modest  airborne  equipage.  The  TIS  service  is  provided  without  any  ground 
controller  involvement. 


3.1.1  Differences  Between  TIS  and  TCAS. 

TIS  provides  traffic  advisories  similar  to  those  of  Traffic  Alert  and  Collision  Avoidance  System- 
Version  I  (TCAS-I),  but  does  not  provide  resolution  advisories.  The  major  functional  difference 
between  TIS  and  TCAS  is  the  source  of  surveillance  data.  TCAS  uses  an  airborne  interrogator 
with  a  1 -second  update  rate,  while  TIS  uses  the  terminal  Mode  S  ground  interrogator  and  its  data 
link  to  provide  about  a  5-second  update  rate.  The  range  accuracy  of  TIS  and  TCAS  are  similar. 
TCAS  angular  accuracy  is  limited  to  a  few  degrees  of  azimuth  measured  with  respect  to  the 
aircraft,  while  TIS  angular  accuracy  is  that  of  Mode  S  (about  1  milliradian)  measured  with 
respect  to  the  ground  interrogator.  These  differences  in  surveillance  accuracy,  coordinate 
system,  and  update  rate  impacted  the  design  of  TIS.  The  algorithms  and  parameters  of  TIS  were 
developed  to  offset  the  differences  in  surveillance  performance  in  order  to  yield  comparable 
alerting  service  to  TCAS-I. 


3.2  TEST  SYSTEM  CONFIGURATION. 

All  testing  was  conducted  at  the  Technical  Center  short-range  radar  test  facility  located  in 
building  269,  on  Mode  S  sensor  #1.  This  Mode  S  sensor  is  integrated  with  a  collocated  Airport 
Surveillance  Radar  Model  9  (ASR-9). 


3 .2. 1  Hardware  Configuration. 

The  hardware  configuration  that  was  used  is  essentially  the  same  as  the  operational  systems 
located  in  the  field,  with  exception  of  the  Aircraft  Reply  and  Interference  Environmental 
Simulator  (ARIES).  The  hardware  testbed  is  shown  in  figure  3.2.1-1  below,  and  consisted  of  the 
following  items: 

a.  Dual-channel  Terminal  Configured  Mode  S  sensor,  with  single  face  antenna 

b.  Collocated  ASR-9  Radar 

c.  Local  Maintenance  Terminal  (LMT) 

d.  Remote  Terminal  (RT) 

e.  Real-Time  Aircraft  Display  System  (RTADS) 

f.  Radar  Intelligence  Tool  (RJT) 

g.  Aircraft  Reply  and  Interference  Environmental  Simulator  (ARIES) 

h.  Two  aircraft  equipped  with  Mode  S  transponders  and  prototype  ADLP/TIS  displays 

i.  Rack-mount  Mode  S  transponders  and  prototype  ADLP/TIS  displays  located  on  top  of 
nearby  Aircraft  Hanger. 
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FIGURE  3.2.1- 1.  MODE  S  HARDWARE  ELEMENTS  OF  TIS  TESTING 


3.2.2  Software  Configuration, 

The  TIS  software  configuration  consisted  of  one  System  Configuration  Management  (SCM) 
controlled  version,  with  two  minor  variants.  The  SCM  version,  SAR214.G,  was  used  for  all  live 
flight-testing,  and  is  the  version  that  will  ultimately  get  fielded.  The  two  minor  variations, 
SAR214G-TIS  DEBUG  and  SAR214G-TISZCONE,  each  contained  a  one-line  change  to 
support  the  ARIES  scenario  testing  and  live-ground  testing  (aircraft  hanger-mounted  transponder 
setup),  respectively. 

SAR214G-TIS  DEBUG  was  required  because  the  test  target  simulator  (ARIES)  did  not  fully 
support  the  data  link  protocol  used  by  TIS.  A  one-line  change  was  made  to  use  pilot-initiated 
downlinks  instead  of  broadcast  downlink  messages  to  request  TIS  service.  SAR214G- 
TISZCONE  was  required  because  of  the  sensors  close  proximity  to  the  ground-based  (aircraft 
hanger-mounted)  transponder  setup  used  during  the  regression  testing.  A  one-line  change  was 
made  to  set  the  zenith  cone  buffer  value  to  zero  so  the  test  transponder  would  be  visible  in  the 
TIS  coverage  volume. 

The  Airborne  Data  Link  Processor  (ADLP)  and  TIS  display  software  used  during  the  TIS  live 
flight  tests  was  prototype  code  installed  on  laptop  personal  computers  (PC).  This  software  was 
not  tested  here  but  merely  used  a  test  tool  to  verify  the  ground-based  TIS  software.  Additional 
testing  will  be  required  at  a  later  date  when  production  ADLPs  are  available. 
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3.3  INTERFACES. 


The  TIS  software  operates  within  the  Terminal  Mode  S  system  and  does  not  interface  directly 
with  any  other  NAS  systems.  It  is  totally  self-contained  within  the  Mode  S  sensor  and  does  not 
affect  surveillance  data  sent  to  Air  Traffic  (AT)  facilities.  The  overall  architecture  of  the  TIS 
software  is  shown  in  figure  3.3-1.  There  are  two  TIS  processing  tasks:  the  tracker,  and  the  alert 
generator.  The  tracker  task  receives  inputs  from  the  sensor  surveillance  functions  and  maintains 
a  local  TIS  track  file  that  is  shared  between  the  TIS  tracker  task  and  alert  generation  task.  TIS 
tracks  are  updated  at  the  time  that  surveillance  inputs  appear.  Any  TIS  messages  generated  in 
the  alert  generation  task  are  fed  to  the  sensor  data  link  functions  for  transmission  to  the  client 
aircraft.  Input  from  the  sensor  data  link  functions  provides  the  source  of  TIS  downlink  request 
messages,  which  enable  or  disable  TIS  service  to  a  particular  client  aircraft.  TIS  also  attaches  to 
the  sensor  software  performance  monitor  and  data  extraction  functions  (not  shown  in  figure 
3.3-1). 


Mailbox 


(Alert,  goodbye,  keep-alive) 


FIGURE  3.3-1.  ARCHITECTURE  OF  THE  TIS  SENSOR  SOFTWARE 
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4.  TEST  AND  EVALUATION  DESCRIPTION. 


The  Test  and  Evaluation  (T&E)  Description  provides  details  on  how  the  TIS  requirements  were 
tested  and  verified.  The  TIS  requirements  were  assigned  to  two  major  test  categories;  DT&E 
and  OT&E.  The  following  three  test  methods  were  used  to  verify  the  requirements  within  the 
DT&E  and  OT&E  test  categories: 


a.  software  code  inspection, 

b.  target  scenario  testing, 

c.  live  flight  testing. 


The  DT&E  requirements  were  verified  using  software  code  inspection  and  analysis  of  test 
scenario  data.  The  OT&E  requirements  were  verified  by  analysis  of  test  scenario  data  and  live 
flight  data.  Each  test  method  was  conducted  using  a  formal  test  procedure  to  ensure  that  all  the 
requirements  were  tested. 


4. 1  SOFTWARE  CODE  INSPECTION. 


This  test  method  was  used  to  verify  requirements  by  visual  examination  against  predefined 
inspection  criteria.  Code  inspections  consisted  of  an  examination  of  code  listings  and  no 
quantitative  data  recording  was  required  other  than  completion  of  procedure  check  sheets. 


4.1.1  Test  Obi  ective/Criteria. 

The  objective  of  this  test  method  was  to  verify  that  the  low-level  TIS  tracking  algorithms  and  the 
alert  processing  routines  function  correctly,  as  defined  in  the  TIS  specification.  The  following 
TVRTM  requirements  were  verified:  1,  12,  14-19,  21-31,  35,  45-66,  68,  70-76,  78,  80,  85-87,  91, 
100,  104,  106,  119,  120,  122-125,  127,  128,  136,  137,  143-150,  153,  158,  160,164-167,  172-182, 
193,  206,  207,  212-225,  229,  230,  238,  240,  247,  251,  256,  258,  266,  268,  276,  280,  284,  285, 
288,  291,  293,  303-305,  307,  322-336,  338-342,  344. 

NOTE:  Detailed  text  for  each  of  the  requirements  listed  above  can  be  found  in  the  TVRTM 
located  in  appendix  C. 


4, 1 ,2  Test  Description. 

The  Code  Inspection  was  conducted  in  a  methodical  and  systematic  manner  using  procedures 
that  matched  specific  software  code  to  a  requirement  that  it  satisfied.  A  source  code  listing  of 
the  SCM  SAR214G  Mode  S  image  provided  the  baseline  for  the  verification,  which  was  done 
manually  by  visual  inspection  for  each  of  the  requirements. 

The  code  inspection  was  conducted  at  the  Technical  Center  in  Atlantic  City,  NJ.  This  effort  was 
started  the  week  of  July  14,  1997,  and  continued  until  completion  on  August  1,  1997.  ACT-3 10 
personnel  performed  the  TIS  software  code  inspection  using  the  Mode  S  TIS  DT&E  and  OT&E 
Code  Inspection  Test  Procedure. 
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4. 1 .3  Data  Collection  and  Analysis  Method. 


No  formal  data  collection  was  required  for  the  code  inspection.  Analysis  consisted  of  visually 
comparing  the  selected  software  code  sequences  to  the  algorithms  in  the  TIS  specification. 


4. 1 .4  Results/Discussion. 

All  the  requirements  verified  in  the  code  inspection  were  100  percent  correct. 

4.1.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified. 


4.2  SCENARIO  TESTING. 


This  test  method  was  used  to  verify  requirements  by  running  test  scenarios  containing  simulated 
targets  that  exercise  the  system  in  predefined,  repeatable  patterns,  while  collecting  data  for  later 
analysis.  Thirty  test  cases  utilizing  37  different  test  scenarios  were  run  to  simulate  various 
aircraft  (client  and  intruder)  flight  paths,  conflict  conditions,  and  Terra/Non-Terra  Mode  S 
operational  environments.  Several  generic  and  TIS  specific  analysis  tools  were  then  used  to 
reduce  the  data.  A  complete  listing  of  all  the  scenarios  used  for  TIS  testing  is  included  in 
appendix  A. 


Within  the  37 

TISCRCL4, 

TISCRDS8, 

TISHOCL4, 

TISHODS8, 

TISOTCL4, 

TISOTDS8, 


scenarios  that  were  utilized,  the  following  group  is  defined  as  the  “basic  18”: 


TISCRL8,  TISCRDS4, 
TISCRLL4,  TISCRLL8, 
TISHOL8,  TISHODS4, 
TISHOLL4,  TISHOLL8, 
TISOTL8,  TISOTDS4, 
TISOTLL4,  TISOTLL8. 


This  set  of  18  test  scenarios,  each  of  which  consist  of  only  2  targets  (client  and  intruder)  in 
various  types  of  encounters,  were  used  to  verify  the  TIS  performance  accuracy.  The  content  and 
success  criteria’ for  these  18  scenarios  is  defined  in  the  TIS  Requirements  Document 
(requirements  349  to  379).  The  resultant  data  extraction  files  have  been  analyzed  to  ensure 
requirement  compliance.  Any  deficiencies  were  analyzed  in  detail  to  determine  the  cause  of  the 
failure.  Failures  due  to  bad  surveillance  data  (input  to  TIS)  were  identified  as  such. 


All  scenario  testing  was  conducted  at  the  Technical  Center,  Mode  S  sensor  #1  (building  269) 
using  the  SAR214G-TIS  DEBUG  software  image  and  ARIES,  between  July  21  and  August  1, 
1997.  All  tests  were  conducted  by  ACT-3 10  personnel  and  support  contractors. 

One  of  the  test  conditions  that  is  common  to  most  all  of  the  scenario  and  live  flight  tests  were  the 
Mode  S  data  types  extracted  during  each  test  run.  They  are  listed  below: 
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2  -  Roll  Call 

5  -  ATCRBS  report 

6  -  Mode  S  report 

9  -  CD2  terminal 

10  -  ASR9  data 

1 1  -  SF  ATCRBS  synch 

12  -  SF  Mode  S  sync 

19  -  Standard  uplink 

20  -  ELM  uplink 

21  -  Downlink  request 

22  -  ATCRBS  ID  request 

23  -  Cancel  request 

24  -  Reject  delay  notice 

25  -  Reject  delay  with  IDs 

26  -  Uplink  deliver  notice 

29  -  ELM  downlink 

30  -  ELM  downlink  position 

3 1  -  Capability  message 

32  -  ATCRBS  ID  message 

33  -  Test  request 

34  -  ATC  fail  recovery  msg 

35  -  ATC  capability  req 


The  following  subsections  contain  the  30 


36  -  Sensor  fail  recov  msg 

37  -  Control  state  msg 

38  -  Test  response  message 

39  -  Status  message 

40  -  Track  alert  message 

41  -  WCP  capability  req 

42  -  State  request 

43  -  Position  request 

44  -  State  message 

45  -  Position  message 

46  -  Track  drop  message 
49  -  Sensor  recov  notice 

78  -  Pilot  downlink 

79  -  Pilot  downlink  position 

80  -  Broadcast  downlink 

81  -  Broadcast  downlink  position 

82  -  Ground  init  downlink 

83  -  Ground  init  downlink  position 

89  -  TIS  track  file 

90  -  TIS  report 

91  -  TIS  alert 

92  -  TIS  request 

t  cases  executed  as  part  of  the  scenario  testing. 


4.2. 1  TEST:  Horizontal  Tracking  and  Turn  Prediction. 

4.2. 1 . 1  Test  Objectives  /  Criteria . 

The  objective  of  this  test  was  to  verify  the  horizontal  velocity  values  for  a  horizontal  track  state 
of  SECOND,  that  the  horizontal  tracker  uses  alpha-beta  smoothing  algorithm  (for  track 
positions)  and  the  turn  detection  algorithm  (for  track  velocities)  for  horizontal  track  states  that 
are  MATURE.  The  following  TVRTM  requirements  were  verified:  138  -  141,  150  (dte). 


4.2. 1 .2  Testing  Description. 

This  test  was  conducted  by  running  the  TISXOVRB  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  a  single  intruder  aircraft  that 
approachs  from  4  miles  to  the  rear  on  an  angle  to  within  1/4  mile  of  the  client.  The  intruder  then 
turns  sharply  and  flys  parallel  to  the  client.  The  scenario  was  run  to  completion  without  any 
special  conditions  set. 
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4.2. 1.3  Data  Collection  and  Analysis. 


The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MXOVRB  1.723. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  that  was 
compared  to  the  data  recorded  during  the  test.  Also,  the  Radar  Beacon  Analysis  Tool  (RBAT) 
TIS  Analysis  tool  was  used  on  the  test  data  so  that  the  results  could  be  looked  at  to  ensure  proper 
operation  of  the  scenario. 

The  analysis  output  files  generated  were  TXOVRB  1.723  from  TIS  Analysis  and 
QXOVRC1T.723  from  the  TIS  Tracker  tool. 


4.2. 1 .4  Results  /  Discussion. 

The  analysis  output  files  were  reviewed  to  verify  track  states,  check  that  the  alpha-beta¬ 
smoothing  algorithm  was  used,  and  check  that  the  turn  detection  algorithm  was  used.  The 
following  TIS  requirements  were  successfully  verified  as  a  result  of  data  analysis  on  the 
TISXOVRB  scenario:  138  -  141  and  150. 

Note  that  during  this  scenario,  although  not  a  part  of  a  specific  requirement,  an  intruder 
crossover  problem  was  shown  to  exist.  As  the  intruder  aircraft  closely  approached  and  then 
turned  away  from  the  client  aircraft,  before  it  crossed  its  path,  was  shown  by  the  TIS  algorithm 
to  have  crossed  the  client’s  track  when  it  in  fact  had  not. 

The  following  reliability  results  were  obtained  from  TIS  Analysis  for  the  data  of  this  scenario. 
The  Traffic  Advisory  is  for  intruders  within  0.5  nautical  mile  (nmi)  and  800  feet  in  altitude  of  the 
client  and  the  Proximity  Advisory  is  for  intruders  within  5  nmi  and  1200  feet  of  the  client.  A 
description  of  the  results  listed  is  shown  in  appendix  D. 

Mode  S  - Traffic  Advisory -  - Proximity  Advisory — 


Client 

Id 

Size 

Rel 

Size 

FAlrm 

Size 

Rel 

Size 

1 

a63796 

13 

100.0 

13 

0.0 

39 

97.4 

38 

TOTAL 

13 

100.0 

13 

0.0 

39 

97.4 

38 

- Reliability - 

FAlrm  Size  Bear  Size  Range  Alt  ARate  Head  Stat 

0.0  51  86.3  51  100.0  96.1  96.1  100.0  98.0 

0.0  51  86.3  51  100.0  96.1  96.1  100.0  98.0 

The  bearing  reliability  is  low  because  the  TIS  tracker  lags  during  sharp  turns  by  the  aircraft. 


4.2. 1.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified. 

A  TIS  intruder  tracking  problem  was  observed  when  a  fast  maneuvering,  intruding  target  flew 
very  close  to  the  client  aircraft.  This  problem  was  initially  observed  during  a  flight  test  of  the 
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OT&E  for  the  Dulles  demo  in  1995.  It  is  referred  to  as  the  "crossover  problem."  This  test 
nario  was  created  to  duplicate  that  flight  test  maneuver.  During  the  scenario,  the  intruder  is 
splayed  for  five  scans  on  the  wrong  side  of  the  client  aircraft  on  the  TIS  display  screen.  This 
rossover  problem  occurs  because  TIS  sends  the  intruder's  predicted  position,  one  scan  ahead, 
and  the  Mode  S  only  gets  updates  once  every  4  to5  seconds.  When  a  fast  approaching  intruder 
gets  within  a  quarter  mile  and  abruptly  turns  (and  doesn't  cross  the  client's  path)  TIS  predicts  the 
intruder  will  appear  on  the  other  side  of  the  client.  It  then  takes  several  scans  for  the  TIS  tracker 
to  correct  this  invalid  prediction.  This  anomaly  was  only  observed  in  this  one  test  case,  within 
35  nmi  of  the  Mode  S  sensor. 


4,2.2  TEST :  Traffic  Alert  Message  and  Ground  Track. 

4.2.2. 1  Test  Objectives  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  the  TIS  Traffic  Alert  messages  are  composed  of  the 
8-bit  MSP  header,  the  6-bit  message  type  field,  and  two  Traffic  Data  Blocks.  Also,  that  the  first 
message  in  each  group  contains  own-aircraft  ground  track  angle;  that  the  value  of  “own_track”  is 
used  in  Message  Type  and  Traffic  Bearing  determination.  The  following  TVRTM  requirements 
will  then  be  verified:  259,  264,  267  (ote). 


4.2.2. 2  Testing  Description. 

This  test  was  conducted  by  running  the  TISCRCL4  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  on  a  Crossing 
course;  Climbing  in  altitude,  starting  45  miles  from  the  sensor  and  the  scenario  was  run  to 
completion  without  any  special  conditions  set. 


4.2.2.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MCRCL41. 721. 

The  TIS  Tracker/ Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  TCRCL41.721  from  TIS  Analysis,  QCRCL41T.721 
from  the  TIS  Tracker  tool  and  LSTCRCL4.721  from  the  TIS  list  program. 

4.2. 2.4  Results  /  Discussion. 

TIS  Traffic  Alert  messages  were  checked  for  the  correct  message  fields  and  the  value  of  own 
track  was  checked  along  with  its  use.  The  following  TIS  requirements  were  verified  as  a  result  of 
data  analysis  on  the  TISCRCL4  scenario:  259,  264,  267. 
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4.2.2. 5  Conclusions. 


All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 


4.2.3  TEST:  TIS  Data  Format  and  Vertical  and  Horizontal  Update. 

4.2.3. 1  Test  Objectives  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  TIS  receives  data  from  the  sensor  in  the  correct  units: 
range  units  (RU),  azimuth  units  (AU),  altitude  (100  feet),  and  time  units  (TU),  also  angles  shall 
be  measured  clockwise  from  North.  When  the  TIS  track  has  had  at  least  two  updates  since  its 
initiation  vertical  and  horizontal  updates  shall  be  performed,  including  any  changes  to  sort  bin 
linkages  based  on  these  projections.  The  following  TVRTM  requirements  will  then  be  verified: 
8-11  (ote)  and  94-96  (dte). 

4.2.3 .2  Testing  Description. 

This  test  was  conducted  by  running  the  TISCRCL8  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  a 
Crossing  course,  a  Climbing  flight,  starting  8  miles  from  sensor  and  was  run  to  completion 
without  any  special  conditions  set. 


4.2.3 .3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MCRCL8 1.721. 

The  TIS  Tracker/ Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  TCRCL81.721  from  TIS  Analysis,  QCRCL81T.721 
from  the  TIS  Tracker  tool  and  LSTCRCL8.721  from  the  TIS  list  program. 


4,2.3  A  Results  /  Discussion. 

The  TIS  messages  and  tracks  were  analyzed  to  ensure  that  the  right  data  units  of  measurement 
were  used.  Also,  the  TIS  output  tracks  were  looked  at  to  verify  that  horizontal  and  vertical 
updates  were  performed  correctly.  The  following  TIS  requirements  were  verified  as  a  result  of 
data  analysis  on  the  TISCRCL8  scenario:  8-1 1  and  94-96. 


4.2.3.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 
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4.2.4  TEST:  Message  Type  Value  and  Traffic  Bearing. 


4.2.4. 1  Test  Objectives  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  the  TIS  keep-alive  message  type  value  and  that  the 
Traffic  Bearing  field  contains  the  bearing  angle  from  the  own-aircraft  to  the  alert  aircraft  in 
range  increments  0  through  59  with  respect  to  the  sensor  ground  track.  The  following  TVRTM 
requirements  will  then  be  verified:  272,  277-279,  296  (ote). 


4. 2.4,2  Testing  Description. 

This  test  was  conducted  by  running  the  TISCRDS4  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  on  a  Crossing 
course;  Descending  in  altitude,  starting  45  miles  from  the  sensor  and  the  scenario  was  run  to 
completion  without  any  special  conditions  set. 


4.2  4.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MCRDS41.721. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  TCRDS41.721  from  TIS  Analysis,  QCRDS41T.721 
from  the  TIS  Tracker  tool  and  LSTCRDS4.721  from  the  TIS  list  program. 


4.2. 4, 4  Results  /  Discussion. 

The  TIS  message  Traffic  Bearing  field  was  checked  for  the  correct  values  and  TIS  keep-alive 
messages  were  checked  to  ensure  that  the  right  values  were  used.  The  following  TIS 
requirements  were  verified  as  a  result  of  data  analysis  on  the  TISCRDS4  scenario:  272,  277-279, 
296. 


4.2.4.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 


4.2.5  TEST:  Slow  Search.  Alert  Determination,  and  Odd  Alert  Count. 
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4,2.5. 1  Test  Objectives  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  a  slow  search  is  equivalent  to  the  fast  search  except 
that  the  range  of  bins  to  search  is  determined  by  the  speed  of  the  input  TIS  track;  that  the  alert 
determination  process  is  called  for  all  potential  alert  tracks  and  computes  the  difference  in  the  x- 
and  y-direction  position  and  velocity;  and  the  altitude  values  (difference  and  absolute)  are 
calculated.  Also,  during  this  test,  when  an  odd  number  of  alerts  occur,  the  following  will  be 
verified;  that  the  second  Traffic  Data  Block  in  the  last  alert  contains  no  traffic  data;  that  the 
traffic  bearing  field  in  last  message  is  set  to  63  and  remaining  15  bits  are  unused;  and  the  3-bit 
Traffic  Heading  field  contains  the  ground  track  angle  of  the  alert  aircraft.  The  following 
TVRTM  requirements  will  then  be  verified:  202-204,  208,  209  (dte)  and  254,  255,  265,  292 
(ote). 


4.2. 5.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISCRDS8  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  on  a  Crossing 
course;  Descending  in  altitude,  starting  8  miles  from  the  sensor  and  the  scenario  was  run  to 
completion  without  any  special  conditions  set. 


4. 2.5.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MCRDS8 1.721. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  TCRDS81.721  from  TIS  Analysis,  QCRDS81T.721 
from  the  TIS  Tracker  tool,  QCRDS81A.721  from  the  TIS  Alert  tool,  and  LSTCRDS8.721  from 
the  TIS  list  program. 

4.2.5.4  Results  /  Discussion. 

The  speed  of  the  TIS  track  was  used  to  check  whether  a  slow  or  fast  search  of  potential  alerts 
was  done.  Then  alert  determination  processing  was  checked  to  make  sure  that  all  alerts  were 
computed  correctly.  Also,  TIS  traffic  alert  messages  were  checked  when  there  was  an  odd 
number  of  alerts  to  make  sure  that  all  corresponding  data  fields  contained  the  right  data.  Finally, 
the  Traffic  Heading  field  of  the  alert  message  was  checked  for  correct  data. 

The  following  TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the  TISCRDS8 
scenario:  202-204,  208,  209,  254,  255,  265,  and  292. 


4, 2,5.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 
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4,2.6  TEST :  Sector  List  Processing  and  Coarse  Screening. 

4.2.6. 1  Test  Objectives  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  the  TIS  tracks  requesting  TIS  service  are  linked  to  the 
sector  list  appropriate  for  their  azimuth  sector;  that  the  TIS  tracks  linked  to  a  sector  list  are 
processed  at  a  later  time;  that  the  TIS  Alert  Generation  task  executes  periodically  to  process 
entries  from  the  sector  lists  generating  uplink  messages,  and  that  a  coarse  screening  process 
searches  the  track  file  for  tracks  close  enough  in  the  horizontal  direction  to  generate  alerts.  The 
following  TVRTM  requirements  will  then  be  verified:  168,  169,  171,  192  (ote). 


4.2.6.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISCRLL4  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  a 
Crossing  course,  at  Level  flight,  starting  45  miles  from  sensor  and  the  scenario  was  run  to 
completion  without  any  special  conditions  set. 


4.2.6, 3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  datatypes  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MCRLL41 .721 . 

The  TIS  Tracker/ Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  TCRLL41.721  from  TIS  Analysis,  QCRLL41T.721 
from  the  TIS  Tracker  tool,  and  LSTCRLL4.721  from  the  TIS  list  program. 


4.2.64  Results  /  Discussion. 

The  TIS  track  files  were  checked  for  correct  processing  of  TIS  requests  and  that  the  sector  lists 
are  used  correctly  when  processing  TIS  tracks  and  generating  alerts  from  them.  Also,  all  alerts 
were  checked  to  ensure  that  the  horizontal  separation  from  the  client  was  right.  The  following 
TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the  TISCRLL4  scenario:  168,  169, 
171,  192. 


4.2.6.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 


4.2.7  TEST:  Current  Position  Comparison  and  Position  Updates. 
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4.2,7. 1  Test  Objective  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  if  the  Mode  S  track  is  receiving  TIS,  the  input  handler 
compares  the  current  position  with  the  TIS  coverage  map,  and  that  the  updated  TIS  tracks  are 
moved  to  their  appropriate  sector  lists.  Also,  for  ATCRBS  messages  that  are  not  track  drops, 
that  the  input  handler  computes  update  time  periods  for  the  horizontal  and  vertical  trackers;  and 
if  all  time  periods  are  positive,  the  input  handler  computes  a  vertical  position  “ZR”  from  the 
message  altitude.  The  following  TVRTM  requirements  will  then  be  verified:  112,  118  (ote)  and 
90,  92  (dte). 


4.2.7.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISCRLL8  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  a 
Crossing  course,  at  Level  flight,  starting  8  miles  from  sensor  and  was  run  to  completion  without 
any  special  conditions  set. 


4, 2,7.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MCRLL8 1.721. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  TCRLL81.721  from  TIS  Analysis,  QCRLL81T.721 
from  the  TIS  Tracker  tool,  and  LSTCRLL8.721  from  the  TIS  list  program. 


4.2.7,4  Results  /  Discussion. 

Mode  S  track  updates  for  TIS  tracks  were  checked  for  the  correct  placement  of  the  tracks. 
Update  time  periods  computed  from  input  ATCRBS  messages  were  compared  with  the  output 
time  periods.  Also,  the  computation  of  vertical  position  (ZR)  was  checked.  The  following  TIS 
requirements  were  verified  as  a  result  of  data  analysis  on  the  TISCRLL8  scenario:  90,  92,  112, 
and  118. 


4.2.7.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 


4.2.8  TEST:  Second  Traffic  Information  Block. 


4.2.8, 1  Test  Objectives  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  in  a  TIS  message,  with  only  one  traffic  aircraft,  the 
Traffic  Bearing  value  is  63  in  the  unused  Traffic  Information  Block  and  that  the  remainder  of  the 
bits  are  set  to  zero  indicating  no  valid  information.  Also,  that  the  Traffic  Range  and  the  Relative 
Altitude  fields  contain  the  correct  data  as  it  relates  to  own-aircraft.  The  following  TVRTM 
requirements  will  then  be  verified:  281-283,  287  (ote). 


4.2. 8,2  Testing  Description. 

This  test  was  conducted  by  running  the  TISHOCL4  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  on  a  Head-On 
course;  Climbing  in  altitude,  starting  45  miles  from  the  sensor  and  the  scenario  was  run  to 
completion  without  any  special  conditions  set. 


4.2.8, 3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MHOCL4 1.721. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test,  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  THOCL41.721  from  TIS  Analysis,  QHOCL41T.721 
from  the  TIS  Tracker  tool  and  LSTHOCL4.721  from  the  TIS  list  program. 


4.2.8.4  Results  /  Discussion. 

The  TIS  messages  were  checked  for  correct  information  when  there  is  only  one  traffic  aircraft. 
Also,  the  contents  of  the  Traffic  Range  field  and  the  Relative  Altitude  field  in  the  Traffic 
Information  Block  were  checked  for  the  correct  contents.  The  following  TIS  requirements  were 
verified  as  a  result  of  data  analysis  on  the  TISHOCL4  scenario:  281-283,  287. 

A  self-alert  was  found  during  the  analysis  of  the  data  for  this  scenario.  It  showed  that  a  code 
swap  had  occurred  causing  the  altitude  of  the  client’s  ATCRBS  track  to  drop  600  feet.  RBAT 
Surveillance  Print  was  used  and  the  output  file  was  SPHOCL4 1.721. 


4.2.8, 5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified. 

An  explanation  for  the  cause  and  affect  of  the  self-alert  found  in  this  scenario  can  be  found  in 
section  4.2.29.5.  This  problem  is  characterized  as  “due  to  surveillance  deficiencies”  and  is  not 
attributed  to  the  TIS  software. 
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4.2.9  TEST :  Altitude  Processing.  Track  and  Alert  Formatting,  and  TERRA  Processing. 


4,2.9. 1  Test  Objectives  /  Criteria. 

The  objective  of  this  test  was  to  verify  the  correct  operation  of  the  altitude  tracker  processing; 
that  each  TIS  track  on  a  sector  list  is  formatted;  and  that  the  data  is  passed  on  to  sensor  data  link 
functions.  Also,  that  additional  processing  is  performed  under  Terra  to  prevent  “self-alerts” 
during  the  alert  determination  process  and  that  the  alerts  are  shown  in  the  extracted  data.  The 
following  TVRTM  requirements  will  then  be  verified:  164  (dte)  and  190,  191,211,  248,  252, 
253  (ote). 


4.2,9.2  Testing  Description, 

This  test  was  conducted  by  running  the  TISHOCL8  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  a 
Head-On  course,  Climbing  during  the  flight,  starting  8  miles  from  sensor. 

a.  The  TISHOCL8  scenario  was  run  once  in  Terra  mode  with  default  SAP  settings  and 
then  the  NONHOCL8  scenario  was  run  for  Non-Terra  mode. 


4.2.9.3  Data  Collection  and  Analysis. 

The  data  extraction  files  were  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S 
using  file  names  MHOCL81.721  and  MNHOCL81.724. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test,  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  THOCL8 1.721  from  TIS  Analysis,  QHOCL81T.721 
from  the  TIS  Tracker  tool,  and  LSTHOCL8.721  from  the  TIS  list  program.  The  Non-Terra 
output  files  were  TNHOCL8 1.724  from  TIS  Analysis. 


4.2.9.4  Results  /  Discussion. 

With  Terra  mode  in  effect,  checks  for  self-alerts  were  made.  Data  extraction  was  verified  and 
altitude  tracker  processing  was  checked.  Also,  all  TIS  uplink  messages,  including  traffic  alert 
messages,  were  checked  for  completeness  and  correct  formatting.  The  following  TIS 
requirements  were  verified  as  a  result  of  data  analysis  on  the  TISHOCL8  and  NONHOCL8 
scenarios:  164,  190,  191,  211,  248,  252,  and  253. 


4.2.9.S  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 
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4.2.10  TEST:  Data  Extraction.  Horizontal  Tracker,  and  Transition  State. 


4.2. 1 0. 1  Test  Objectives  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  the  data  extraction  of  all  TIS  categories  works 
correctly;  that  ground  range  and  input  report  azimuth  are  used  to  compute  the  reports  x-y 
coordinates;  that  for  ATCRBS  track  updates  the  TIS  horizontal  tracker  updates  the  horizontal 
components  of  the  TIS  track  and  any  changes  in  the  TIS  track  sort  bin  linkages  are  performed; 
that  when  the  “trans_flag”  is  TRUE  then  the  Transition  State  update  is  performed,  otherwise,  the 
No  Transition  State  update  is  performed;  that  the  altitude  tracking  function  works  correctly;  and 
that  the  initial  altitude  processing  works  correctly.  The  following  TVRTM  requirements  will 
then  be  verified:  105,  347,  348  (ote)  and  101-103,  159,  161,  162  (dte). 


4.2.10.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISHODS5  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  a 
Head-On  course,  at  Descending  flight,  starting  45  miles  from  sensor  and  was  run  to  completion 
without  any  special  conditions  set. 


4.2.10.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MHODS5 1.721. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  THODS5 1.721  from  TIS  Analysis,  QHODS51T.721 
from  the  TIS  Tracker  tool,  QHODS51  A.721  from  the  TIS  Alert  tool,  and  LSTHODS5.721  from 
the  TIS  list  program. 

4.2. 10.4  Results  /  Discussion. 

All  data  extraction  results  were  checked  for  correctness.  The  TIS  reported  x-y  coordinates  were 
verified.  The  TIS  horizontal  tracker  updates  were  checked.  Transition  State  outputs  were 
verified  and  TIS  altitude  state  outputs  were  checked. 

The  following  TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the  TISHODS5 
scenario:  101-103,  105,  159,  161,  162,  347,  and  348. 


4.2.10.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 
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4,2. 1 1  TEST :  Mature  Track  Request  and  Track  Entries. 


4.2. 11.1  Test  Objectives  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  each  mature  track  requesting  service  received  either 
traffic  data  or  keep-alive  uplink  messages  at  least  every  60  seconds  and  that  the  TIS 
alerts/message  category  include  the  track  entries  for  the  client  and  intruder  tracks.  The  following 
TVRTM  requirements  would  then  be  verified:  337,  346  (ote). 


4.2. 1 1 .2  Testing  Description. 

This  test  was  conducted  by  running  the  TISHODS8  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  on  a  Head-On 
course;  Descending  in  altitude,  starting  8  miles  from  the  sensor  and  the  scenario  was  run  to 
completion  without  any  special  conditions  set. 


4,2, 1 1 .3  Data  Collection  and  Analysis, 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MHODS8 1.721. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  THODS81.721  from  TIS  Analysis,  QHODS81T.721 
from  the  TIS  Tracker  tool,  and  LSTHODS8.721  from  the  TIS  list  program. 


4.2. 1 1 .4  Results  /  Discussion. 

The  clients  aircraft  data  was  checked  to  make  sure  it  got  either  a  keep-alive  message  or  traffic 
data  every  60  seconds.  Also,  the  TIS  track  data  was  checked  to  make  sure  both  client  and 
intruder  data  was  present.  The  following  TIS  requirements  were  verified  as  a  result  of  data 
analysis  on  the  TISHODS8  scenario:  337  and  346. 


The  following  reliability  results  were  obtained  from  TIS  Analysis  for  the  data  of  this  scenario.  A 
description  of  the  results  listed  is  shown  in  appendix  D. 


Mode  S  - Traffic  Advisory -  - Proximity  Advisory 
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Id 
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4 
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4 
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42 
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40 
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40 
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Reliability 
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44 
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44 
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100.0 
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0.0 

44 
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44 

100.0 
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100.0 
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This  scenario  has  extra  intruders  (0003  &  0004)  that  are  short-time  targets.  At  the  end  of  their 
time  periods  they  both  coast  without  bearing  and  altitude  data  because  of  the  way  the  ARIES 
scenario  is  written.  This  is  the  reason  why  the  bearing  and  altitude  results  are  less  than  1 00 
percent. 


4.2.11.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern  except  for  the  low  bearing  reliability  as  explained 
previously.  This  problem  is  characterized  as  “due  to  surveillance  deficiencies”  and  is  not 
attributed  to  the  TIS  software. 


4.2.12  TEST:  Sensor  Surveillance  Processing  and  Coordinate  Conversion. 

4.2. 12. 1  Test  Objective  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  the  TIS  tracker  task  receives  inputs  from  the  sensor 
surveillance  processing  functions  and  maintains  a  local  TIS  track  file;  that  TIS  tracks  receiving 
TIS  service  are  linked  to  their  appropriate  sector  lists;  and  that  position,  altitude,  and  time  are 
taken  from  the  surveillance  track  file  entiy  after  it  is  updated  by  the  input  report.  Also,  when  the 
input  ATCRBS  message  is  a  track  update,  the  handler  converts  the  report  coordinates  from 
range-azimuth  to  x-y  with  the  first  step  being  to  calculate  the  report  ground  range  using  the 
report  vertical  position  ZR.  The  following  TVRTM  requirements  will  then  be  verified:  77,  79, 
84  (ote)  and  98,  99  (dte). 


4.2.12.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISHOLL4  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  a 
Head-On  course,  at  Level  flight,  starting  45  miles  from  sensor  and  was  run  to  completion 
without  any  special  conditions  set. 


4.2. 12.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
filename  MHOLL4 1.721. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test,  and  the  DR  TIS  List  program  was  used  to  list  the 
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TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  THOLL41.721  from  TIS  Analysis  and  QHOLL41T.721 
from  the  TIS  Tracker  tool. 


4.2. 12.4  Results  /  Discussion. 

All  TIS  track  outputs  were  listed  and  checked  for  correctness.  Also,  x  -  y  coordinates  and 
vertical  positions  (ZR)  were  verified  for  ATCRBS  type  messages.  The  following  TIS 
requirements  were  verified  as  a  result  of  data  analysis  on  the  TISHOLL4  scenario:  77,  79,  84,  98, 
and  99. 

Analysis  of  the  data  for  this  scenario  found  that  a  self-alert  occurred.  The  self-alert  was  caused 
by  a  code  swap,  which  in  turn  caused  an  azimuth  difference  in  the  tracking  of  the  clients 
ATCRBS  ID.  Also,  after  the  code  swap,  for  one  scan  there  was  no  ATCRBS  report  except  one 
for  an  unknown  ID  0003.  Finally,  when  recovering  from  the  code  swap  the  altitudes  for  CD’s 
0001  and  0002  were  swapped  for  one  scan.  RBAT  Surveillance  Print  was  used  for  this  analysis 
and  the  output  file  was  SPHOLL4 1.721. 

The  following  reliability  results  were  obtained  from  TIS  Analysis  for  the  data  of  the  scenario.  A 
description  of  the  results  listed  is  shown  in  appendix  D. 

Mode  S  - Traffic  Advisory - 

Client  Id  Size  Rel  Size  FAlrm 

1  faaOOl  9  100.0  11  18.2 

TOTAL  9  100.0  11  18.2 

- Reliability — 

FAlrm  Size  Bear  Size  Range  Alt  ARate  Head  Stat 

0.0  26  100.0  29  96.6  86.2  93.1  100.0  100.0 

0.0  26  100.0  29  96.6  86.2  93.1  100.0  100.0 

Note  that  the  altitude  reliability  is  below  the  90  percent  success  rate.  This  is  directly  attributed  to 
the  self-alert  and  code  swap  found  in  this  scenario. 


— Proximity  Advisory 
Size  Rel  Size 
20  100.0  20 
20  100.0  20 


4.2.12.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified. 

An  explanation  for  the  cause  and  affect  of  the  self-alert  found  in  this  scenario  can  be  found  in 
section  4.2.29.5.  This  problem  is  characterized  as  “due  to  surveillance  deficiencies”  and  is  not 
attributed  to  the  TIS  software. 
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4.2.13  TEST:  Tracker  and  Alert  Generation  and  TAU. 


4.2,13.1  Test  Objectives/ Criteria. 

The  objective  of  this  test  was  to  verify  the  correct  operation  of  the  tracker  and  alert  generation 
tasks,  the  processing  of  a  TIS  track  update  during  level  flight,  and  the  determination  that  threat 
and  proximity  alerts  can  be  calculated  correctly  using  the  “tau”  value.  Also,  that  the  tau  values 
are  passed  to  the  data  extraction  function.  The  following  TVRTM  requirements  will  then  be 
verified:  2-6,  241  (ote)  and  163,  226-228  (dte).. ''  ' 


4.2.13,2  Testing  Description. 

This  test  was  conducted  by  running  the  TISHOLL8  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  a 
Head-On  course,  at  Level  flight,  starting  8  miles  from  sensor  and  was  run  to  completion  without 
any  special  conditions  set. 


4.2.13.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MHOLL81.721. 

The  TIS  Tracker/ Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  THOLL81.721  from  TIS  Analysis,  QHOLL81T.721 
from  the  TIS  Tracker  tool,  QHOLL81 A  from  the  TIS  Alert  tool,  and  LSTHOLL8.721  from  the 
TIS  list  program 


4.2.13.4  Results  /  Discussion. 

TIS  tracks  and  alerts  were  listed  and  verified  for  correct  updates.  This  proved  the  correct 
operation  of  the  TIS  tracker  and  alert  generation  tasks.  In  this  scenario,  with  no  altitude 
transition,  TIS  track  updates  have  a  value  difference  of  no  more  than  a  foot  from  the  analysis 
tool.  Also,  all  TAU  values  were  checked  for  correctness  with  vertical  and  horizontal  TAU’s 
having  a  difference  of  less  than  8  seconds  from  that  calculated  by  the  analysis  tool.  The 
following  TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the  TISHOLL8  scenario: 
2-6,  163,  226-228,  and  241. 


4.2.13.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 
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4.2, 14  TEST:  Traffic  Information  Block  and  Keep-Alive  Message. 


4£.  14.1  Test  Objective  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  the  Altitude  Rate  and  the  Traffic  Status  fields  contain 
the  correct  flata  as  it  relates  to  the  alert  aircraft.  Also,  that  a  “keep-alive”  message  is  generated  to 
the  selected  airciaft  that  had  traffic  on  the  previous  scan  and  the  current  update  does  not,  and  that 
the  remaining  42  bits  of  the  “keep-alive”  message  are  set  to  zero.  The  following  TVRTM 
requirements  will  then  be  verified:  289,  294,  295,  297  (ote). 


4,2.14.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISOTCL4  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  on  an  Overtaking 
course,  Climbing  in  altitude,  starting  45  miles  from  the  sensor  and  the  scenario  was  run  to 
completion  without  any  special  conditions  set. 


4,2.14.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MOTCL4 1.722. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  TOTCL41.722  from  TIS  Analysis,  QOTCL41T.722 
from  the  TIS  Tracker  tool,  and  LSTOTCL4.722  from  the  TIS  list  program. 


4,2, 14,4  Results  /  Discussion. 

The  Altitude  Rate  field  for  TIS  alert  was  checked  for  a  correct  climbing  indication.  The  Traffic 
Status  field  was  checked  for  proximity  and  traffic  indications.  The  TIS  alert  messages  were 
checked  to  make  sure  that  a  goodbye  message  was  generated  when  a  previous  scan  had  traffic  for 
the  client  aircraft  and  the  current  scan  does  not.  Lastly  it  was  checked  that  the  last  42  bits  of  a 
TIS  keep-alive  message  are  cleared  to  zero.  The  following  TIS  requirements  were  verified  as  a 
result  of  data  analysis  on  the  TISOTCL4  scenario:  289,  294,  295,  and  297. 


4.2.14.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 
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4.2. 1 5  TEST:  Horizontal  Tracker  Update  and  Altitude  Tracker. 

4.2.15.1  Test  Objective  /  Criteria. 

The  objective  of  this  test  was  to  verify  that  the  horizontal  tracker  update  period  is  at  least  2 
seconds;  that  the  horizontal  tracker  updates  the  TIS  track’s  sort  bin  linkage  for  tr^ks  whose  state 
is  THIRD  or  MATURE;  that  the  driver  for  the  TIS  altitude  tracker  computes  the  altitude 
projected  to  the  current  time;  that  the  TIS  altitude  tracker  driver  sets  variables  for  the  various 
altitude  tracker  states;  and  when  the  TIS  tracks  altitude  state  is  INITIALIZE  processing  for  the 
initialization  state  is  performed.  The  following  TVRTM  requirements  will  then  be  verified:  126, 
151,  154,  156,  157  (dte). 


4.2.15.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISOTCLS  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  an 
Overtaking  course,  Climbing  flight,  starting  8  miles  from  sensor  and  was  run  to  completion 
without  any  special  conditions  set. 


4  2  1 5.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MOTCL8 1.722. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  TOTCL81.722  from  TIS  Analysis,  QOTCL81T.722 
from  the  TIS  Tracker  tool,  and  LSTOTCL8.722  from  the  TIS  list  program. 

4.2.15.4  Results  /  Discussion. 

The  TIS  tracker  outputs  were  checked  to  make  sure  that  the  horizontal  tracker  function  was 
working  correctly.  The  same  outputs  were  then  checked  to  verify  the  correct  operation  of  the 

TIS  altitude  tracker.  0 

The  following  TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the  TISOTCLS 

scenario:  126,  151,  154,  156,  and  157. 


4.2.15.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 
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4.2. 16  TEST;  Altitude  Rate  and  Message  Format. 

4.2, 16. 1  Test  Objective  /  Criteria 

The  objective  of  this  test  is  to  verify  that  the  Altitude  Rate  field  contains  the  correct  data  as  it 
relates  to  the  alert  aircraft  and  is  processed  by  the  sensor  software  data  link  function.  Also,  that 
the  uplink  messages  are  in  “Comm- A”  56-bit  format  and  that  no  uplink  message  has  a  number  of 
zero.  The  following  TVRTM  requirements  will  then  be  verified:  289,  301,  302,  306  (ote). 


4.2.16.2  Testing  Description 

This  test  was  conducted  by  running  the  TISOTDS4  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  on  an  Overtaking 
course;  Descending  in  altitude,  starting  45  miles  from  the  sensor  and  the  scenario  was  run  to 
completion  without  any  special  conditions  set.  Data  type  48  (Active  Message  List)  is  added  to 
extraction  types  for  requirement  306. 


4.2.16.3  Data  Collection  and  Analysis 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MOTDS4 1 . 723 . 


The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  The  RBAT  Miscellaneous  Print  option  was  used  to  display 
message  numbers.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that  the  results  could 
be  looked  at  to  ensure  proper  operation  of  the  scenario. 

RBAT  Miscellaneous  Print  was  on  the  output  file  selecting  data  type  48  to  verify  message 
numbers. 

The  analysis  output  files  generated  were  TOTDS41.723  from  TIS  Analysis,  QOTDS41T  723 
from  the  TIS  Tracker  tool,  LSTOTDS4.723  from  the  TIS  list  program,  and  MPOTDS4 1.723 
from  RBAT  Miscellaneous  Print. 


4,2. 16.4  Results  /  Discussion 

The  format  of  all  TIS  uplink  messages  was  checked.  This  included  the  2-bit  altitude  rate  field. 
Also,  using  RBAT  Miscellaneous  Print  option  the  message  numbers  were  checked,  including  the 
non-use  of  number  zero.  The  following  TIS  requirements  were  verified  as  a  result  of  data 
analysis  on  the  TISOTDS4  scenario:  289,  301,  302,  and  306. 

Analysis  of  the  data  for  this  scenario  showed  that  a  self-alert  had  occurred.  The  self-alert  was 
caused  because  of  a  code  swap  and  a  coasting  condition  which  made  the  clients  ATCRBS 
altitude  drop  1100  feet.  RBAT  Surveillance  Print  was  used  for  this  with  an  output  file  of 
SPOTDS4 1.723. 


27 


4  2.16.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified. 


An  explanation  for  the  cause  and  affect  of  the  self-alert  found  in  this  scenario  can  be  found  in 
section  4.2.29.5.  This  problem  is  characterized  as  “due  to  surveillance  deficiencies  and  is  not 

attributed  to  the  TIS  software. 


4  2 .17  TF-ST:  Uplink  Message  Format. 

4  2  1 7. 1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  the  format  of  the  uplink  messages  (Mode  S  Comm-A):  size 
Mode  S  Specific  Protocol  (MSP)  header,  message  type,  and  Traffic  Data  Blocks.  The  following 
TVRTM  requirements  will  then  be  verified:  242-246  (ote). 


4  9  17  2  Testing  Description. 

This  test  was  conducted  by  running  the  TISOTDS8  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  on  an  Overtaking 
course;  Descending  in  altitude,  starting  8  miles  from  the  sensor  and  the  scenario  was  run  o 
completion  without  any  special  conditions  set. 


4  2.17.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode 
file  name  MOTDS8 1.722. 


S  using 


The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  1. St  *e 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  TOTDS8 1 .722  from  TIS  Analysis,  QOTDS8 1  T.722 
from  the  TIS  Tracker  tool,  and  LSTOTDS8.722  from  the  TIS  list  program. 


4.2.17.4  Results  /  Discussion. 

All  TIS  uplink  messages  were  listed  and  the  contents  were  checked  for  correctness.  The  Mode  S 
Specific Prlcol  header,  the  message  type  field,  and  the  Traffic  Data  Blocks  were  all  checked 

Thefollowing  TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the  TISOTDS8 
scenario:  242-246. 

Analysis  of  the  data  for  this  scenario  showed  that  a  false 

intruder  were  not  near  each  other.  Further  analysis  revealed  that  both  the  client  (ATCRBSID 
0001)  and  the  intruder  (ATCRBS  ID  0002)  had  code  swaps  at  this  time  causing  altitude  and 
range  discrepancies.  These  discrepancies  showed  target  reports  that  were  closer  to  each  ot 


28 


than  actuality,  thereby  causing  the  alert.  This  code  swapping  can  be  traced  to  the  “Terra  fix” 
problem.  RBAT  Surveillance  Print  was  used  for  this  analysis  with  an  output  file  of 
SPOTDS8 1.722.  See  section  4.2.29.5  for  further  details. 


4.2.17.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern  except  for  the  false  alert  problem  described  previously. 
This  problem  is  characterized  as  “due  to  surveillance  deficiencies”  and  is  not  attributed  to  the 
TIS  software. 


4.2.18  TEST:  Generation  Timing.  Coarse  Screening.  Altitude  Rate,  and  Generation  of  a  Traffic 
Block. 


4.2. 1 8. 1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  that  for  each  TIS  track  on  a  sector  list  the  alert  generation 
timing  test  is  performed  and  the  coarse  screening  procedure  is  invoked  to  find  potential  traffic 
tracks  which  are  checked  for  alerts;  and  that  the  2-bit  Altitude  Rate  field  indicates  a  3  (level). 
Also,  to  verify  the  correct  generation  of  a  Traffic  Data  Block  to  project  the  position  of  the  traffic 
and  own-aircraft.  The  following  TVRTM  requirements  will  then  be  verified:  183-185,  289  (ote) 
and  275  (dte). 

4.2.18.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISOTLL4  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  an 
Overtaking  course,  at  Level  flight,  starting  45  miles  from  sensor  and  was  run  to  completion 
without  any  special  conditions  set. 


4.2.18.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MOTLL4 1.722. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test,  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  TOTLL41.722  from  TIS  Analysis,  QOTLL41T.722 
from  the  TIS  Tracker  tool,  QOTLL41  A. 722  from  the  TIS  Alert  tool,  and  LSTOTLL4.722  from 
the  TIS  list  program. 
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4.2. 1 8.4  Results  /  Discussion. 


All  TIS  tracks  were  looked  at  to  make  sure  that  alert  generation  was  performed  correctly  and  at 
the  right  time.  The  Altitude  Rate  field  of  the  TIS  uplink  message  was  checked  for  the  correct 
code.  The  TIS  Traffic  Data  was  checked  to  make  sure  that  it  was  projected  correctly  from  the 
radar  scan  time.  The  following  TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the 
TISOTLL4  scenario:  183-185,  275,  and  289. 

Analysis  of  the  data  for  this  scenario  showed  that  a  self-alert  had  occurred.  A  coasting  condition 
had  caused  the  clients  ATCRBS  ID  to  increase  its  altitude  by  500  feet.  RBAT  Surveillance  Print 
was  used  for  this  analysis  with  an  output  file  of  SPOTLL41 .722. 


4.2.18.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified. 

An  explanation  for  the  cause  and  affect  of  the  self-alert  found  in  this  scenario  can  be  found  in 
section  4.2.29.5.  This  problem  is  characterized  as  “due  to  surveillance  deficiencies”  and  is  not 
attributed  to  the  TIS  software. 

4.2.19  TEST:  Track  File.  Sector  List.  Magnetic  Deviation  Angle  SAP.  TIS  Tracker,  and  Ranee 
Encoding. 

4.2.19.1  Test  Objective/ Criteria. 

The  objective  of  this  test  is  to  verify  that  TIS  maintains  a  separate  track  file;  that  each  TIS  track 
is  on  a  sector  list  according  to  current  azimuth  and  the  tracker  links  tracks  on  the  sector  lists. 
Also,  that  TIS  uses  a  TIS  Magnetic  Deviation  Angle  SAP  to  uplink  the  magnetic  North-corrected 
own-aircraft  ground-track  field;  that  the  TIS  tracker  attaches  active  tracks  to  their  appropriate 
sort  list  and  TIS-supported  tracks  to  their  appropriate  sector  list;  and  that  the  range  encoding  for 
alert  aircraft  exceeding  30  nmi  are  correct.  The  following  TVRTM  requirements  will  then  be 
verified:  13,  32,  33,  44,  67,  69  (ote)  and  286  (dte). 


4.2.19.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISOTLL8  scenario  on  the  ARIES  while  collecting 
Mode  S  data  extractions.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  an 
Overtaking  course,  at  Level  flight,  starting  8  miles  from  sensor  and  was  successfully  run  to 
completion.  This  scenario  was  also  run  with  the  TIS  Magnetic  Deviation  Angle  SAP  set  to  zero 
for  comparison  of  data  associated  with  that  SAP  (requirement  44). 


4.2.19.3  Data  Collection  and  Analysis. 

The  data  extraction  files  were  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S 
using  file  names  MOTLL8 1.723  and  MOTLL8A1.724. 
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The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Data  collected  from  the  second  run  with  TIS  Magnetic 
Deviation  Angle  set  to  zero  was  analyzed  and  compared  to  the  data  from  the  first  run.  Also,  the 
TIS  Analysis  tool  was  used  on  the  test  data  so  that  the  results  could  be  looked  at  to  ensure  proper 
operation  of  the  scenario. 

The  analysis  output  files  generated  were  TOTLL8 1.723  from  TIS  Analysis,  QOTLL81T  from 
the  TIS  Tracker  tool  and  LSTOTLL8.723  from  the  TIS  list  program.  Also,  the  output  files  from 
the  scenario  run  with  the  Magnetic  Deviation  Angle  set  to  zero  were  TOTLL8A1 .724  from  TIS 
Analysis  and  LSTOTLL8.724  from  the  TIS  list  program. 


4.2.19.4  Results  /  Discussion. 

Each  TIS  track  was  looked  at  to  prove  that  it  was  sorted,  computed,  and  linked  correctly.  Two 
runs  of  the  scenario  were  analyzed  to  ensure  that  the  TIS  Magnetic  Deviation  SAP  has  the  proper 
effect  on  TIS  tracking.  It  was  also  checked  that  at  more  than  30  miles  from  the  sensor  the  range 
encoding  is  collapsed  to  account  for  increased  cross-range  error.  The  following  TIS 
requirements  were  verified  as  a  result  of  data  analysis  on  the  TISOTLL8  scenario:  13,  32,  33,  44, 
67,  69,  and  286. 


4.2.19.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 


4,2.20  TEST:  Tracker  Operation  During  Coasts  and  Altitude  State. 

4.2.20. 1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  the  correct  operation  of  data  extraction  for  coasts  and  drops; 
that  the  interface  works  correctly  between  the  sensor  and  the  TIS  tracker  for  coasts  and  drops; 
that  if  an  ATCRBS  message  is  a  coast  or  drop  ZR  is  set  to  the  TIS  tracks  vertical  position  or  to 
the  lesser  of  0.5  nmi  and  one-half  of  the  tracks  range;  that  track  firmness  is  updated  for  ATCRBS 
messages;  that  for  coasts  the  TIS  tracks  vertical  position  is  set  to  ‘coast  alt’  and  no  further 
processing  is  done;  that  if  the  TIS  tracks  altitude  state  is  TREND  and  the  value  of  the  tracks 
altitude  residual  is  >105  feet,  then  the  reset  smoothing  procedure  is  performed;  and  that  if  either 
track  lacks  a  clear  altitude  value  then  dz  =  dalt  =  0.  The  following  TVRTM  requirements  will 
then  be  verified:  114.5,  121  (ote)  and  82,  93,  97,  155,  160,  210  (dte). 

4.2.20.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISHCSP4  and  TISHCSPX  scenarios  on  the  ARIES 
while  collecting  Mode  S  data  extractions.  The  TISHCSP4  scenario  includes  one  TIS  client  and 
one  intruder  aircraft  on  a  Head-On  course,  Climbing  flight,  starting  45  miles  from  sensor  with  a 
loss  of  client  and  intruder  beacon  information  to  create  track  coasts  and  track  drops.  The 
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scenario  was  run  to  a  successful  completion.  The  TISHCSPX  scenario  includes  one  TIS  client 
and  one  intruder  aircraft  on  a  Head-On  course,  Climbing  flight,  starting  45  miles  from  sensor 
with  a  loss  of  client  and  intruder  altitude  information  to  create  track  coasts  and  track  drops.  The 
scenario  was  run  to  a  successful  completion. 


4.2.20.3  Data  Collection  and  Analysis. 

The  data  extraction  files  were  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S 
using  file  names  MHCSP4 1.723  and  MHCSPX1.723. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario,  and  the  RB  AT 
Surveillance  File  Analysis  tool  was  used  to  ensure  proper  operation  with  track  coasts  and  drops. 
The  analysis  output  files  generated  from  the  TISHCSP4  scenario  were  THCSP41.723  from  TIS 
Analysis,  QHCSP4T.723  from  the  TIS  Tracker  tool,  QHCSP4A.723  from  the  TIS  Alert  tool, 
LSTHCSP4.723  from  the  TIS  list  program,  and  SFHCSP41.723,  SFHCSP42.723,  and 
SFHCSP43.723  from  RBAT  Surveillance  file  analysis.  The  analysis  output  files  generated  from 
the  TISHCSPX  scenario  were  THCSPX1.723  from  TIS  Analysis,  QHCSPXT.723  from  the  TIS 
Tracker  tool,  LSTHCSPX.723  from  the  TIS  list  program,  and  SFHCSPX1.723,  SFHCSPX2.723, 
and  SFHCSPX3.723  from  RBAT  Surveillance  file  analysis. 


4.2,20.4  Results  /  Discussion. 

The  data  collection  files  were  checked  to  verify  that  the  aircraft  whose  altitude  was  not  clear 
level  are  considered  out  of  coverage.  All  tracker  tasks  associated  with  coasts  and  drops  were 
verified  for  correctness.  For  AT CRB S  coasts  and  drops  ZR  and  TIS  track  firmness  were 
checked.  Also,  TIS  track  Reset  Smoothing  was  determined  to  work  correctly.  The  following  TIS 
requirements  were  verified  as  a  result  of  data  analysis  on  the  TISHCSP4  and  TISHCSPX 
scenarios:  82,  93,  97,  114.5,  121,  155,  160,  and  210. 

The  following  reliability  results  were  obtained  from  TIS  Analysis  for  the  TISHCSPX  data  of  that 
scenario.  A  description  of  the  results  listed  is  shown  in  appendix  D. 

Mode  S  - Traffic  Advisory -  - Proximity  Advisory — 

Client  Id  Size  Rel  Size  FAlrm  Size  Rel  Size 

1  faaOOl  12  100.0  12  0.0  47  100.0  47 

TOTAL  12  100.0  12  0.0  47  100.0  47 

- Reliability - 

FAlrm  Size  Bear  Size  Range  Alt  ARate  Head  Stat 

0.0  54  100.0  59  100.0  94.9  89.8  100.0  96.6 

0.0  54  100.0  59  100.0  94.9  89.8  100.0  96.6 
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Note  that  the  Altitude  Rate  is  less  than  the  90  percent  reliability  requirement.  This  occurs 
because  there  are  missing  ATCRBS  reports  and  a  garbled  ID.  Therefore,  the  altitude  input  for 
the  summary  report  is  lacking  some  data. 


4,2.20.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified. 

The  low  altitude  rate  problem  can  be  linked  to  the  “Terra  fix”  problem  as  discussed  in  section 
4.2.29.5.  This  problem  is  characterized  as  “due  to  surveillance  deficiencies”  and  is  not  attributed 
to  the  TIS  software. 


4.2.21  TEST:  Altitude  Rate  Threshold. 


4,2.21.1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  that  an  altitude  change  rate  of  less  than  500  feet  per  minute 
will  be  classified  as  level  flight.  The  following  TVRTM  requirements  will  then  be  verified:  290 
ote). 


4.2.21,2  Testing  Description. 

This  test  was  conducted  by  running  the  TISHCSP8  and  TISHDSP8  scenarios  on  the  ARIES 
while  collecting  Mode  S  data  extractions.  The  TISHCSP8  scenario  includes  one  TIS  client  and 
one  intruder  aircraft  on  a  Head-On  course,  a  Climbing  flight,  starting  8  miles  from  sensor  and 
was  run  to  completion  with  the  climb  rate  of  the  intruder  aircraft  at  400  feet  per  minute.  The 
TISHDSP8  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  a  Head-On  course,  a 
Descending  flight,  starting  8  miles  from  sensor  and  was  run  to  completion  with  the  descent  rate 
of  the  intruder  aircraft  at  due  to  loss  of  altitude  400  feet  per  minute. 


4,2.21.3  Data  Collection  and  Analysis. 

The  data  extraction  files  were  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S 
using  file  names  MHCSP8 1.723  and  MHDSP8 1.723. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  THCSP8 1.723  from  TIS  Analysis  for  the  TISHCSP8 
scenario,  and  THDSP8 1.723  from  TIS  Analysis  for  the  TISHDSP8  scenario. 
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4.2.21.4  Results  /  Discussion. 

The  data  collection  files  were  checked  to  ensure  that  the  altitude  rates  above  500  feet  per  minute 
were  used  and  those  below  were  not.  The  following  TIS  requirement  was  verified  as  a  result  of 
data  analysis  on  the  TISHCSP8  and  TISHDSP8  scenarios:  290. 


4.2.21.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 


4.2.22  TEST:  Sort  Bin  Linkage  Update. 

4.2.22,1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  that  with  a  track  state  of  THIRD  or  MATURE  and  a  change 
in  speed  classification  or  if  the  track  has  moved  from  one  bin  to  another,  then  the  sort  bin 
linkages  are  updated.  The  following  TVRTM  requirement  will  then  be  verified:  138,  152  (dte). 


4.2.22.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISHLSP4  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  a 
Head-On  course,  at  Level  flight,  starting  45  miles  from  sensor  and  was  run  to  completion  with 
the  speed  of  the  intruder  aircraft  increasing  to  280  knots  during  the  scenario. 


4.2.22.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MHLSP4R2.818. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  THLSP4R2.818  from  TIS  Analysis  and  QHLSP4T.723 
from  the  TIS  Tracker  tool. 


4.2.22.4  Results  /  Discussion. 

The  data  collection  file  was  checked  to  verify  that  when  a  track’s  horizontal  speed  changes,  then 
the  updates  continue  unaffected.  The  following  TIS  requirement  was  verified  as  a  result  of  data 
analysis  on  the  TISHLSP4  scenario:  138,  152. 


34 


4.2.22.5  Conclusions. 


All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 


4.2.23  TEST:  TIS  Client  Speed  Increase  Sort  Bin. 

4.2.23.1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  that  a  search  is  anchored  at  the  sort  bin  list  that  contains  the 
input  TIS  track,  and  a  fast  search  tests  the  TIS  tracks  at  the  input  track’s  sort  bin  and  the  eight 
neighboring  ones.  The  following  TVRTM  requirements  will  then  be  verified:  194,  195  (dte). 


4.2.23.2  Testing  Description. 

This  test  was  conducted  by  running  the  TISHLSP8  scenario  on  the  ARIES  while  collecting  a 
Mode  S  data  extraction.  The  scenario  includes  one  TIS  client  and  one  intruder  aircraft  on  a 
Head-On  course,  a  Level  flight,  starting  8  miles  from  sensor  and  was  run  to  completion  with  the 
client’s  speed  increasing  to  280  knots. 


4.2.23,3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  MHLSP8 1.723. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  THLSP8 1.723  from  TIS  Analysis  and  QHLSP8T.723 
from  the  TIS  Tracker  tool. 


4.2.23.4  Results  /  Discussion. 

All  TIS  tracks  were  checked  to  make  sure  that  they  were  sorted  according  to  the  track  speed,  fast 
or  slow.  The  following  TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the 
TISHLSP8  scenario:  194  and  195. 


4.2.23.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 


35 


4.2.24  TEST:  TERRA  and  Non-TERRA  Mode. 


4,2.24. 1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  that  for  each  ATCRBS  message  the  tracker  task  updates  the 
TIS  track  and  sort  bin  linkages;  for  Terra  mode,  only  ATCRBS  tracks  are  sent  to  alert 
determination;  when  not  in  Terra  mode  both  ATCRBS  and  Mode  S  tracks  are  sent  to  alert 
determination;  and  for  Terra  mode,  only  ATCRBS  tracks  from  the  TIS  track  file  are  considered 
for  potential  alerts.  The  following  TVRTM  requirements  will  then  be  verified:  88,  126,  200, 
201,  205  (ote). 


4.2.24.2  Testing  Description. 

These  tests  were  conducted  by  running  the  TIS200  and  NON200  scenarios  on  the  ARIES,  with 
Terra  and  Non-Terra  mode  in  effect,  and  collecting  Mode  S  data  extractions.  TIS200  has  150 
ATCRBS  targets  and  50  TIS  client  aircraft  flying  in  close  proximity  to  each  other. 

a.  The  Non-Terra  scenario  was  run  with  Terra  mode  off  to  collect  data  for  the  Non-Terra 
requirements. 


4.2.24,3  Data  Collection  and  Analysis. 

The  data  extraction  files  were  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S 
using  file  names  M2002.729  and  MN2001.724. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data,  which  was 
compared  to  the  data,  recorded  during  the  test.  The  DR  TIS  List  program  was  used  to  list  the  TIS 
alerts  sent  in  roll  call  messages  and  see  if  they  were  from  ATCRBS  or  Mode  S  tracks.  Also,  the 
TIS  Analysis  tool  was  used  on  the  test  data  so  that  the  results  could  be  looked  at  to  ensure  proper 
operation  of  the  scenario. 

The  analysis  output  files  generated  were  T2002.729  from  TIS  Analysis  for  the  Terra  run,  and 
TN2001 .724  from  TIS  Analysis  for  the  Non-Terra  run. 


4.2.24,4  Results  /  Discussion. 

The  horizontal  tracker  update  period  was  checked  for  correct  operation.  Also  it  was  shown  that 
with  Terra  mode  in  effect,  only  ATCRBS  tracks  were  used  by  TIS  and  with  Terra  mode  not  in 
effect,  both  ATCRBS  and  Mode  S  tracks  were  used  by  TIS  for  alert  determination.  The 
following  TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the  TIS200  and  NON200 
scenarios:  88,  126,  200,  201,  and  205. 


The  following  reliability  results  were  obtained  from  TIS  Analysis  for  the  Terra  run  of  the 
scenario.  A  description  of  the  results  listed  is  shown  in  appendix  D. 
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Mode  S  - Traffic  Advisory -  - Proximity  Advisory — 

Client  Id  Size  Rel  Size  FAlrm  Size  Rel  Size 

TOTAL  1711  90.0  1839  16.3  23101  99.6  23060 

- Reliability - 

FAlrm  Size  Bear  Size  Range  Alt  ARate  Head  Stat 

0.2  24374  90.8  24543  99.3  97.5  23.9  98.4  98.9 

The  following  reliability  results  were  obtained  from  TIS  Analysis  for  the  Non-Terra  run  of  the 
scenario: 

Mode  S  - Traffic  Advisory - Proximity  Advisory — 

Client  Id  Size  Rel  Size  FAlrm  Size  Rel  Size 

TOTAL  1618  100.0  1618  0.0  23488  99.9  23510 

- Reliability - 

FAlrm  Size  Bear  Size  Range  Alt  ARate  Head  Stat 

0.1  25014  92.9  25094  99.8  99.9  27.1  99.9  99.6 

Note  the  increase  in  reliability  of  the  Non-Terra  version  over  the  Terra  version. 


4.2.24.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified. 

The  Non-Terra  version  of  the  scenario  produced  better  results.  The  reason  for  this  is  discussed 
in  section  4.2.29.5. 


4.2.25  TEST:  TIS  Service  Request  and  SAP. 

4.2.25.1  Test  Objective/ Criteria. 

The  objective  of  this  test  is  to  verify  that  requests  for  TIS  service  are  handled  correctly;  that  the 
TIS  SAPs  can  be  accessed  and  changed;  that  goodbye  messages  are  recognized  and  processed 
correctly  including  those  for  the  zenith  cone;  that  TIS  keep-alive  messages  are  sent  correctly;  and 
that  the  message  fields  for  keep-alive  and  goodbye  messages  are  formatted  correctly.  Also,  that 
ATCRBS  track  drops  are  handled  correctly;  that  Mode  S  messages,  including  track  drops,  are 
handled  correctly;  that  horizontal  track  updates  for  horizontal  track  states  of  FIRST  and 
SECOND  are  initialized  and  computed  correctly.  Verify  that  the  above  functions  occurred  by 
analysis  of  the  Data  Extractions.  The  following  TVRTM  requirements  will  then  be  verified:  20, 
34,  36-38,  41-43,  81,  113-117,  249,  250,  257,  263,  269,  273,  295,  298-300  (ote)  and  89,  106-108, 
129-135  (dte). 


4.2.25.2  Testing  Description. 

These  tests  were  conducted  by  running  the  TIS441  IS  scenario  on  the  ARIES  and  collecting 
Mode  S  data  extractions.  The  TIS441  IS  scenario  contains  six  client  aircraft  that  fly  into  or  out 
of  TIS  coverage  to  verify  the  requirements  as  follows: 
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a.  Before  running  the  scenario,  on  the  Local  Maintenance  Terminal,  verify  all  TIS  SAPs  are 
installed  on  sensor  and  that  the  SAP  values  are  correctly  set.  (34,  41,  43) 

b.  One  run  was  with  all  the  SAP  values  set  to  the  default  settings  for  the  following 
requirements:  (20,  42,  81,  89,106-108,  113,  114,  117,  129-135,  249,  250,  257,  263,  269, 
273,  295,  298,  299,  300) 

c.  One  run  was  with  the  TIS  Enable/Disable  SAP  disabled  to  test  that  no  TIS  processing 
will  take  place  during  this  condition.  (36,  37,  38) 

d.  One  run  was  with  the  Zenith  Cone  Angle  changed  from  the  default  setting  to  70  to  ensure 
that  settings  can  be  changed  and  that  “goodbye”  messages  are  sent  at  the  correct  times. 
(115,116) 


4.2.25.3  Data  Collection  and  Analysis. 

The  data  extraction  files  were  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S 
using  file  names  M441 11.725,  M441 12.725,  M441 13.725,  and  M4411S1.724. 

The  TIS  Tracker/ Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  that  was 
compared  to  the  data  recorded  during  the  test.  The  DR  TIS  List  program  was  used  to  list  the  TIS 
alerts  sent  in  roll  call  messages  and  to  list  the  uplink  and  downlink  messages  sent  to  and  received 
from  the  TIS  aircraft  as  it  flies  into,  through,  and  out  of  the  zenith  cone  and  while  entering  and 
exiting  the  sensor  coverage  area. 

Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that  the  results  could  be  looked  at  to 
ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  T441 1 1.725,  T441 12.725,  T441 13.725,  and 

T441 1S1.724  from  TIS  Analysis,  Q441 1 1T.725  from  the  TIS  Tracker  tool,  and  LST441 1 1.725 

from  the  TIS  list  program. 


4.2.25,4  Results  /  Discussion. 

All  TIS  SAP’s  were  tested  to  ensure  that  they  could  be  changed  to  the  correct  values.  The  output 
with  the  TIS  flag  disabled  was  reviewed  to  see  that  TIS  did  not  operate.  When  the  Zenith  Cone 
Angle  was  changed  the  output  was  checked  to  see  that  the  targets  went  into  it  at  the  proper  time. 
Goodbye  messages  for  aircraft  going  out  of  coverage  or  into  the  zenith  cone  were  checked  for, 
including  looking  for  message  type  62  and  the  remainder  of  the  message  set  to  zero.  Keep-alive 
messages  were  seen  to  occur  at  the  proper  time.  The  value  of  the  TIS  message  type  field  was 
checked  for  correctness.  Dropped  tracks  were  removed  correctly  from  TIS  tracking.  Also, 
horizontal  tracking  through  the  first  and  second  track  updates  was  checked  for  correct  operation 
of  all  tracker  fields.  The  following  TIS  requirements  were  verified  as  a  result  of  data  analysis  on 
the  TIS4411S  scenario:  20,  34,  36-38,  41-43,  81,  89,  106-108,  113-117,  129-135,  249,  250,  257, 
263,  269,  273,  295,  and  298-300. 
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4.2.25.5  Conclusions. 


All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 


4.2.26  TEST:  Self-Alert.  Mature  TIS  Track  and  Uplink  Message. 

4.2.26,1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  that  the  client  track  does  not  self-alert;  that  MATURE  TIS 
tracks  are  evaluated  for  alert  generation;  and  that  alerts  on  the  input  list  which  have  equal  ranges 
are  then  sorted  by  time.  Also,  that  TIS  uplink  messages  may  contain  one  or  two  alerts;  that  the 
message  type  field  indicates  the  correct  type;  and  that  the  Traffic  Information  Block  contains  the 
following  fields:  Traffic  Bearing,  Traffic  Range,  Relative  Altitude,  Altitude  Rate  Traffic 
Heading,  and  Traffic  Status.  The  following  TVRTM  requirements  will  then  be  verified:  198, 
199  (dte)  and  261,  263,  274  (ote). 


4.2.26.2  Testing  Description. 

This  test  was  conducted  by  running  the  TIS4421  scenario  on  the  ARIES  while  collecting  a  Mode 
S  data  extraction.  The  scenario  includes  one  TIS  client  flying  outbound  on  a  radial  situated 
between  two  intruder  aircraft  flying  one  degree  to  the  left  and  right,  and  the  scenario  was  run  to 
completion  without  any  special  conditions  set. 


4.2.26,3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  M4421 1.722. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test,  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  T4421 1.722  from  TIS  Analysis,  Q4421T.722  from  the 
TIS  Tracker  tool,  Q4421A.722  from  the  TIS  Alert  tool,  and  LST4421.722  from  the  TIS  list 
program. 


4.2.26.4  Results  /  Discussion. 

The  TIS  tracker  output  file  was  checked  to  make  sure  that  no  self-alerts  were  generated.  All 
non-mature  tracks  did  not  generate  traffic  alerts.  Each  TIS  uplink  message  contained 
information  on  only  one  or  two  traffic  alerts.  The  TIS  traffic  data  message  was  checked  for  the 
correct  message  type  and  the  correct  information  in  the  Traffic  Information  Blocks.  The 
following  TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the  TIS4421  scenario: 
198,  199,261,263,  and  274. 
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4.2.26.5  Conclusions. 


All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 


4.2.27  TEST:  Alert  Generation  and  Message  Type, 

4.2.27, 1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  that  each  TIS  track  is  tested  for  alert  generation;  that  there 
are  two  categories  of  alerts  (proximity  and  threat);  and  that  the  alert  lists  contain  determination 
taus  and  square  of  the  range  between  the  input  TIS  track  and  the  track  generating  the  alert.  Also, 
to  be  tested  is  that  the  alert  processing  shall  generate  prioritized  alert  lists  in  the  correct  format  to 
be  uplinked  to  client  aircraft.  Testing  will  show  that  all  types  of  messages  are  generated  and  that 
the  last  message  in  the  group  has  a  message  type  of  61 .  The  following  TVRTM  requirements 
will  then  be  verified:  186-189,  271  (ote)  and  196,  197  (dte). 


4.2.27.2  Testing  Description. 

This  test  was  conducted  by  running  the  TIS4422  scenario  on  the  ARIES  while  collecting  a  Mode 
S  data  extraction.  The  scenario  contains  three  groups  of  five  targets,  each  containing  one  TIS 
client  with  four  intruders  causing  proximate  and  traffic  advisories.  The  three  groups  differ  by  the 
number  of  traffic  advisories  versus  the  number  of  proximate  advisories,  1  to  3,  2  to  2,  and  3  to  1. 
The  clients  all  fly  outbound,  on  a  radial,  and  the  intruders  also  fly  outbound,  sometimes  on  the 
same  radial  but  at  a  different  altitude  and  sometimes  on  a  radial  1 0  to  the  right  or  left  of  the 
client.  The  scenario  was  run  to  completion  without  any  special  conditions  set. 


4,2.27.3  Data  Collection  and  Analysis. 

The  data  extraction  file  was  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S  using 
file  name  M44221.722. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  T44221.722  from  TIS  Analysis,  Q4422A.722  from  the 
TIS  Alert  tool,  and  LST4422.722  from  the  TIS  list  program. 


4.2.27.4  Results  /  Discussion. 

All  TIS  alerts  are  generated  correctly  and  determined  to  be  either  a  proximity  or  threat.  The 
alerts  were  sent  to  the  client  aircraft  in  priority  order.  Messages  other  than  traffic  alerts  (i.e., 
goodbye  and  keep-alive)  are  also  sent  to  the  client.  Also,  it  was  determined  that  the  final  TIS 
alert  message  in  a  group  has  a  message  type  set  to  61 .  The  following  TIS  requirements  were 
verified  as  a  result  of  data  analysis  on  the  TIS4422  scenario:  186  -  189,  196,  197,  and  271. 
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Analysis  of  the  data  for  this  scenario  showed  that  self-alerts  had  occurred  for  two  of  the  three 
clients.  Self-alerts  happened  three  times  for  client  ATCRBS  ID  0001  and  twice  for  client 
ATCRBS  ID  0006.  These  self-alerts  were  a  result  of  coasting  conditions  caused  by  code  swaps 
with  the  altitude  confidence  dropping  to  zero.  RBAT  Surveillance  Print  analysis  was  used  for 
this  with  output  files  of  SP44221.722  and  SP44226.722. 

The  following  reliability  results  were  obtained  from  TIS  Analysis  for  the  data  of  the  scenario.  A 
description  of  the  results  listed  is  shown  in  appendix  D. 


Mode  S 
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1  96.7 

0.0 
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521  98.8  95.8  93.5 
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3  97.3 

0.0 

1541 

85.9 

1541  99.1  94.2  90.0 

98. 

2  97.0 

Note  that  the  bearing  reliability  is  below  the  90  percent  success  rate.  This  can  be  attributed  to 
the  “Terra  fix”  problem  discussed  in  section  4.2.29.5. 


4.2.27.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified. 

An  explanation  for  the  cause  and  affect  of  the  self-alert  found  in  this  test  can  be  found  in  section 
4.2.29.5. 


4,2.28  TEST:  Alert  Sorting.  Prioritizing  and  Message  Type. 

4.2.28.1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  the  alerts  are  sorted,  then  prioritized  by  increasing  range 
within  the  proximity  and  threat  lists.  Also,  that  individual  alert  messages  are  grouped  by 
“Number  of  Traffic  Aircraft”  and  “Structure  of  Group”,  and  that  if  a  TIS  alert  message  is  an 
intermediate  message  in  the  group  the  message  type  field  shall  be  set  to  the  value  60.  The 
following  TVRTM  requirements  will  then  be  verified:  236,  237  (dte)  and  231-233,  262,  270 
(ote). 
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4.2.28.2  Testing  Description. 

This  test  was  conducted  by  running  the  TIS4423  scenario  on  the  ARIES  while  collecting  a  Mode 
S  data  extraction.  The  scenario  includes  one  TIS  client  and  eight  intruder  aircraft;  four  of  the 
intruders  will  generate  proximate  advisories  and  four  of  the  intruders  will  generate  traffic 
advisories.  The  scenario  was  run  to  completion  without  any  special  conditions  set. 

A  Non-Terra  run  was  also  made  with  the  scenario  NON4423  to  assist  in  priority  ordering  process 
verification. 


4.2.28.3  Data  Collection  and  Analysis. 

The  data  extraction  files  were  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S 
using  file  names  M4423 1.722  and  MN4423 1.724. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  T4423 1.722  from  TIS  Analysis,  Q4423T.722  from  the 
TIS  Tracker  tool  and  LST4423.722  from  the  TIS  list  program. 

4.2.28.4  Results  /  Discussion. 

All  alerts  sent  to  client  aircraft  were  checked  to  make  sure  that  alert  priority  ordering  (by 
increasing  range  separation)  takes  place.  This  was  done  for  the  Terra  as  well  as  the  Non-Terra 
runs.  If  the  range  separation  of  two  alerts  is  equal  then  the  earlier  occurring  alert  is  sent  first.  It 
was  confirmed  that  individual  alert  messages  are  grouped  by  Number  of  Traffic  Aircraft  and 
Structure  of  Group.  Also,  for  intermediate  TIS  alert  messages  it  was  shown  that  the  message 
type  field  was  set  to  the  value  of  60. 

The  following  TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the  TIS4423 
scenario:  231-233,  236,  237,  262,  and  270. 

During  the  analysis  of  the  results  it  was  noted  that  there  were  not  always  eight  intruders  being 
sent  to  the  client  even  though  there  were  always  eight  of  them  appearing  in  the  scenario.  RBAT 
Surveillance  Print  analysis  showed  this  to  be  caused  by  the  fact  that  ATCRBS  ID  0002  had  its 
altitude  jump  to  92500  feet  and  later  to  drop  to  0  feet.  These  altitudes  did  not  cause  a  conflict 
and  therefore  this  intruder  did  not  show  up  as  an  alert  at  these  times.  Also,  ATCRBS  ID  0005 
had  its  altitude  drop  to  0  feet  causing  it  to  be  dropped  as  an  intruder  at  that  time. 

Self-alerts  occurred  on  two  separate  occasions  during  this  scenario.  The  first  happened  because 
the  client  ID  developed  a  range  difference  of  0.36  nmi  during  a  portion  of  the  scenario.  The 
other  self-alert  occurred  when  then  client  ID  developed  an  altitude  difference  of  up  to  500  feet 
during  the  scenario.  In  both  cases,  when  the  differences  receded  to  minimal  values,  the  self¬ 
alerts  disappeared.  Analysis  of  the  data  showed  that  code  swaps  occurred  to  cause  these 
discrepancies.  The  RBAT  Surveillance  Print  program  was  used  for  this  with  the  output  file  of 
SP4423SA.722. 
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The  results  from  the  analysis  of  the  data  for  the  Non-Terra  version  of  the  scenario  showed  that 
there  were  no  self-alerts  and  that  all  eight  intruders  were  sent  to  the  client  as  intruders  during 
their  appearance  in  the  scenario.  This  showed  that  there  were  no  instances  of  dropped  targets 
due  to  garbling  or  other  problems.  The  Non-Terra  output  analysis  file  was  TN4423 1 .724  from 
TIS  Analysis. 

The  following  reliability  results  were  obtained  from  TIS  Analysis  for  the  Terra  run  of  the 
scenario.  A  description  of  the  results  listed  is  shown  in  appendix  D. 
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Note  the  bearing  reliability  of  83.1  percent  is  below  the  90  percent  mark  set  in  the  guidelines. 

The  following  reliability  results  were  obtained  from  TIS  Analysis  for  the  Non-Terra  run  of  the 
scenario: 

Mode  S  - Traffic  Advisory -  - Proximity  Advisory 

Client  Id  Size  Rel  Size  FAlrm  Size  Rel  Size 

1  faaOOl  585  100.0  585  0.0  576  100.0  576 

TOTAL  585  100.0  585  0.0  576  100.0  576 

- Reliability - 

FAlrm  Size  Bear  Size  Range  Alt  ARate  Head  Stat 

0.0  1161  94.7  1161  100.0  100.0  100.0  100.0  100.0 

0.0  1161  94.7  1161  100.0  100.0  100.0  100.0  100.0 

The  reliability  is  acceptable  in  all  instances  for  the  Non-Terra  version  of  the  scenario. 


4.2,28.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified. 

The  self-alerts  and  the  dropping  of  intruder  information  can  be  traced  to  two  problems  that 
occurred  during  scenario  and  live  flight  testing.  The  self-alerts  occur  when  TIS  mistakenly 
identifies  the  client’s  own  aircraft  as  an  intruder  and  sends  an  alert  message.  This  problem  is  a 
result  of  the  Mode  S  sensor  temporary  "Terra  fix."  The  "Terra  fix"  was  implemented  to  detect 
defective  transponders  manufactured  by  the  Terra  Corporation.  In  "Terra"  mode,  both  a  Mode  S 
and  ATCRBS  track  are  generated  for  each  Mode  S  target.  Occasionally,  when  garbling  or  poor 
detection  has  occurred,  TIS  mistakenly  identifies  this  ATCRBS  track  as  an  intruder  (to  the  client 
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Mode  S  track),  and  sends  an  advisory  message  to  the  client,  which  is  shown  on  the  TIS  display 
as  being  directly  on  top  of  the  client.  This  additional  ATCRBS  target  report,  resulting  from  the 
garbling  condition,  is  also  part  of  the  normal  ATC  disseminated  surveillance  data. 

The  dropped  intruder  information  occurred  because  of  the  “Terra  fix”  problem  and  because  of  a 
Mode  S  altitude  detection  problem.  Occasionally,  for  some  unexplained  reason,  the  Mode  S 
would  falsely  report  an  aircraft's  altitude  at  some  extremely  large  value  (i.e.,  92,500  feet)  for  one 
scan,  and  then  return  it  back  to  normal  the  following  scans.  However,  this  inaccurate  reporting 
of  altitude  for  ATCRBS  targets  did  result  in  TIS  dropping  intruders,  as  was  the  case  in  this 
scenario.  It  should  be  noted  that  neither  one  of  these  problems  is  TIS  based  and  the  TIS  software 
does  not  need  to  be  fixed  to  correct  them. 

Note  that  since  there  were  no  problems  encountered  with  the  Non-Terra  run  of  the  scenario,  all 
discrepancies  can  be  traced  back  to  the  “Terra  fix”  thereby  verifying  the  TIS  programming. 


4.2.29  TEST:  Maximum  Alert  List  Message  Processing. 

4.2.29. 1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  the  maximum  number  of  eight  alerts  in  an  alert  output  list; 
that  the  proximity  alerts  are  added  to  the  lists  when  there  are  less  than  eight  threat  alerts;  and  that 
the  output  lists  are  sent  to  the  TIS  message  formation  processing.  The  following  TVRTM 
requirements  will  then  be  verified:  234,  235,  239,  260  (ote). 


4.2.29,2  Testing  Description. 

This  test  was  conducted  by  running  the  TIS4424  scenario  on  the  ARIES  while  collecting  a  Mode 
S  data  extraction.  The  scenario  includes  1  TIS  client  and  12  intruder  aircraft.  The  12  intruders 
will  fly  so  as  to  cause  12  advisories  to  be  generated  at  1  time  and  the  scenario  was  run  to 
completion  without  any  special  conditions  set. 

a.  A  Non-Terra  run  was  also  made  with  the  scenario  NON4424  to  assist  in  priority 
ordering  process  verification. 


4.2.29.3  Data  Collection  and  Analysis. 

The  data  extraction  files  were  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S 
using  file  names  M44241.722  and  MN4424 1.724. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test,  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  T4424 1.722  from  TIS  Analysis,  Q4424T.722  from  the 
TIS  Tracker  tool,  and  LST4424.722  from  the  TIS  list  program. 
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4.2.29.4  Results  /  Discussion. 


The  list  of  all  TIS  alerts  sent  to  the  client  aircraft  were  reviewed  to  ensure  that  a  maximum  of 
eight  alerts  were  sent  at  one  time  and  that  they  were  in  priority  order  from  traffic  to  proximity. 
The  following  TIS  requirements  were  verified  as  a  result  of  data  analysis  on  the  TIS4424 
scenario:  234,  235,  239,  and  260. 

During  the  analysis  of  the  results  it  was  noted  that  while  there  were  always  eight  intruders  being 
sent  as  alerts  to  the  client,  they  were  not  always  the  eight  highest  in  priority  ordering  as  required 
by  the  program.  RB  AT  Surveillance  Print  analysis  showed  this  to  be  caused  by  the  fact  that 
ATCRBS  ID’s  0002,0003,0004,0005,  and  0007  had  their  altitude  values  garble  and  drop  to  0  feet 
at  various  times  during  the  scenario.  These  altitude  changes  did  not  cause  a  conflict  and 
therefore,  the  intruders  did  not  show  up  as  an  alert  at  these  times.  When  these  intruders  were 
coasting  and  not  being  considered  for  alerts,  other  intruders  of  the  12  in  this  scenario  were  being 
used  to  fill  in  the  8  total  alerts  being  sent  to  the  client.  The  result  of  this  was  that  the  eight 
closest  in  priority  intruders  were  not  always  being  sent  to  the  client. 

Self-alerts  occurred  on  two  separate  occasions  during  this  scenario.  The  first  happened  because 
the  client  ID  developed  an  azimuth  difference  of  0.59°  during  a  portion  of  the  scenario.  The 
other  self-alert  occurred  when  the  client  ID  developed  an  altitude  difference  of  400  feet  during 
the  scenario.  In  both  cases,  when  the  differences  receded  to  minimal  values,  the  self-alerts 
disappeared.  Analysis  of  the  data  showed  that  in  both  cases,  the  altitude  confidence  for  the  self¬ 
alerts  was  zero.  In  the  case  of  the  azimuth  difference,  the  target  was  coasting.  The  RB  AT 
Surveillance  Print  program  was  used  for  this  analysis  and  the  output  file  of  SP4424SA.722. 

The  results  from  the  analysis  of  the  data  for  the  Non-Terra  version  of  the  scenario  showed  that 
there  were  no  self-alerts  and  that  all  of  the  eight  closest  intruders  were  sent  to  the  client  as  alerts 
during  their  appearance  in  the  scenario.  This  showed  that  there  were  no  instances  of  dropped 
targets  due  to  garbling  or  other  problems.  The  Non-Terra  output  analysis  file  was  TN44241 .724 
from  TIS  Analysis. 

The  following  reliability  results  were  obtained  from  TIS  Analysis  for  the  Terra  run  of  the 
scenario.  A  description  of  the  results  listed  is  shown  in  appendix  D. 

Mode  S  - Traffic  Advisory -  - Proximity  Advisory 

Client  Id  Size  Rel  Size  FAlrm  Size  Rel  Size 

1  faaOOl  406  98.8  406  1.2  755  97.5  739 

TOTAL  406  98.8  406  1.2  755  97.5  739 

- Reliability - 

FAlrm  Size  Bear  Size  Range  Alt  ARate  Head  Stat 

0.4  1137  84.9  1137  97.4  92.2  94.1  96.6  97.4 

0.4  1137  84.9  1137  97.4  92.2  94.1  96.6  97.4 

The  following  reliability  results  were  obtained  from  TIS  Analysis  for  the  Non-Terra  run  of  the 
scenario: 
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Mode  S  - Traffic  Advisory -  - Proximity  Advisory 

Client  Id  Size  Rel  Size  FAlrm  Size  Rel  Size 

1  faaOOl  499  100.0  499  0.0  637  99.8  637 

TOTAL  499  100.0  499  0.0  637  99.8  637 

- Reliability - 

Falrm  Size  Bear  Size  Range  Alt  ARate  Head  Stat 

0.2  1135  93.6  1135  100.0  100.0  100.0  99.9  98.9 

0.2  1135  93.6  1135  100.0  100.0  100.0  99.9  98.9 

The  reliability  is  acceptable  in  all  instances  for  the  Non-Terra  version  of  the  scenario. 


4.2,29.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified. 

The  self-alerts  and  the  dropping  of  intruder  information  can  be  traced  to  two  problems  that 
occurred  during  scenario  and  live  flight  testing.  The  self-alerts  occur  when  TIS  mistakenly 
identifies  the  client’s  own  aircraft  as  an  intruder  and  sends  an  alert  message.  This  problem  is  a 
result  of  the  Mode  S  sensor  temporary  "Terra  fix."  The  "Terra  fix"  was  implemented  to  detect 
defective  transponders  manufactured  by  the  Terra  Corporation.  In  "Terra"  mode,  both  a  Mode  S 
and  ATCRBS  track  are  generated  for  each  Mode  S  target.  Occasionally,  when  garbling  or  poor 
detection  has  occurred,  TIS  mistakenly  identifies  this  ATCRBS  track  as  an  intruder  (to  the  client 
Mode  S  track),  and  sends  an  advisory  message  to  the  client,  which  is  shown  on  the  TIS  display 
as  being  directly  on  top  of  the  client.  This  additional  ATCRBS  target  report,  resulting  from  the 
garbling  condition,  is  also  part  of  the  normal  ATC  disseminated  surveillance  data. 

The  dropped  intruder  information  occurred  because  of  the  “Terra  fix”  problem  and  because  of  a 
Mode  S  altitude  detection  problem.  Occasionally,  for  some  unexplained  reason,  the  Mode  S 
would  falsely  report  an  aircraft's  altitude  at  some  extremely  large  value  (i.e.,  92,500  feet)  for  one 
scan,  and  then  return  it  back  to  normal  the  following  scans.  However,  this  inaccurate  reporting 
of  altitude  for  ATCRBS  targets  did  result  in  TIS  dropping  intruders,  as  was  the  case  in  this 
scenario.  It  should  be  noted  that  neither  of  these  problems  is  TIS  based  and  the  TIS  software 
does  not  need  to  be  fixed  to  correct  them. 

Note  that  since  there  were  no  problems  encountered  with  the  Non-Terra  run  of  the  scenario,  all 
discrepancies  can  be  traced  back  to  the  “Terra  fix”  thereby  verifying  the  TIS  programming. 


4,2.30  TEST:  TIS  Aircraft  Requesting  Service. 

4.2.30.1  Test  Objective  /  Criteria. 

The  objective  of  this  test  is  to  verify  the  correction  operation  of  the  TIS  Maximum  Aircraft 
Supported  SAP  for  the  maximum  number  of  TIS  aircraft  requesting  service  and  maximum  legal 
value  allowed  by  sensor.  The  following  TVRTM  requirements  will  then  be  verified:  39  and  40 
(ote). 
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4,2.30.2  Testing  Description. 

These  tests  were  conducted  by  running  the  UNBRAMP  scenario  on  the  ARIES  while  collecting 
Mode  S  data  extractions.  This  scenario  starts  with  50  TIS  clients  and  then  increases  the  number 
by  10  every  2  minutes  until  it  reaches  200  TIS  clients.  The  scenario  was  run  multiple  times  with 
the  SAP  values  changed  as  follows: 

a.  First,  the  SAP  value  was  manually  varied  to  exceed  the  value  of  the  TIS  Maximum 
Aircraft  Supported  SAP  to  710.  This  is  an  illegal  value  for  this  SAP  and  was  rejected. 
Seven  hundred  is  the  maximum  legal  value  for  this  SAP. 

Returned  the  SAP  setting  to  50  and  ran  the  scenario  to  completion. 

b.  Ran  the  scenario  a  second  time.  Changed  the  TIS  Maximum  Aircraft  Supported  SAP 
value  to  25  when  loading  SAPs  and  then  ran  scenario  to  completion. 


4.2,30.3  Data  Collection  and  Analysis. 

The  data  extraction  files  were  collected  with  data  types  shown  in  section  4.2.2  at  the  Mode  S 
using  file  names  MUNBRMP  1.723  and  MUNBRMP2.725. 

The  TIS  Tracker/Alert  analysis  tool  was  used  to  calculate  tracker  and  alert  data  which  was 
compared  to  the  data  recorded  during  the  test  and  the  DR  TIS  List  program  was  used  to  list  the 
TIS  alerts  sent  in  roll  call  messages.  Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that 
the  results  could  be  looked  at  to  ensure  proper  operation  of  the  scenario. 

The  analysis  output  files  generated  were  TUNBRMP 1.723  and  TUNBRMP2.725  from  TIS 
Analysis  of  the  two  scenario  runs. 


4.2.30.4  Results  /  Discussion. 

The  Maximum  Aircraft  Supported  SAP  was  verified  by  changing  its  value  to  an  illegal  value  that 
was  not  accepted  by  the  program.  Then  the  scenario  was  run  twice  at  two  different  SAP  values 
and  the  output  of  TIS  analysis  showed  that  the  number  of  aircraft  actually  supported  matched  the 
currently  used  SAP  value.  The  following  TIS  requirements  were  verified  as  a  result  of  data 
analysis  on  the  TIS4424  scenario:  39  and  40. 


4.2.30.5  Conclusions. 

All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  There  are  no 
outstanding  or  new  points  of  concern. 
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4.3  LIVE  WORLD  FLIGHT  TESTING. 


Two  FAA  Technical  Center  aircraft  (N39  and  N49)  were  used  for  the  live  flight  tests.  Aircraft 
N39  was  equipped  with  a  General  Aviation  (GA)  Mode  S  transponder  (Bendix/King  KT-70) 
with  one  antenna  and  was  designated  as  the  client.  Aircraft  N49  was  equipped  with  a 
commercial  Mode  S  Transponder  unit  with  upper  and  lower  antennas  and  was  designated  as  the 
intruder.  Both  aircraft  were  equipped  with  a  prototype  ADLP  and  TIS  display  (PC  laptop-based) 
that  was  used  to  simultaneously  record  and  display  data  sent  to  each  aircraft.  Data  was  also 
extracted  at  the  Mode  S  sensor. 

A  total  of  13  different  flight  events  (A  through  L,  and  X)  consisting  of  various  flight  formations, 
encounters,  and  maneuvers  were  conducted,  over  a  2-day  period.  A  preflight  briefing  conducted 
by  the  lead  pilot  was  held  prior  to  each  flight  to  ensure  the  team  knew  the  planned  event 
sequence,  altitudes,  and  radio  frequencies,  etc.  This  was  done  to  ensure  the  safety  of  the  test 
personnel,  pilots,  and  the  aircraft  while  successfully  completing  all  the  TIS  test  events. 

Flight  test  procedures  and  a  flight  log  book  were  provided  for  each  aircraft.  These  procedures 
contained  instructions  for  setup  and  use  of  the  PC  ADLP  and  TIS  display  functions,  a  complete 
set  of  the  planned  flight  events,  and  file  naming  conventions,  etc.  Similarly,  a  test  procedures 
and  log  book  were  provided  for  the  Mode  S  sensor.  It  contained  scripts  that  identified  which 
SAP  files  to  use;  system  hardware  setups;  data  extraction  types  and  file  naming  conventions,  etc. 
All  test  activity  was  logged  in  the  logbooks. 

Data  analysis  was  used  to  evaluate  and  correlate  the  live  flight  data  extractions.  The  RB AT  was 
used  to  verify  the  OT&E  test  requirements.  The  test  team  also  had  log  listings  from  the 
ADLP/TIS  display  to  review,  which  included  all  data  transmissions  to  the  aircraft  from  the  Mode 
S/TIS  software. 

Formal  live  flight  testing  using  the  SAR214G  Mode  S  image  was  conducted  on  July  17  and  18, 
1997,  with  FAA  pilots,  ACT-310  staff,  and  contracted  personnel.  The  flights  originated  from  the 
Technical  Center  in  Atlantic  City,  NJ.  The  Mode  S  sensor  (Sensor  #  1)  is  located  in  building  269 
at  the  Technical  Center. 


4.3.1  TEST:  Live  World  Flight  No.  1. 

4.3 .1.1  Test  Obiective/Criteria. 

The  objective  of  this  test  is  to  verify  that  the  TIS  tracker  receives  surveillance  inputs,  maintains  a 
tracker  file,  and  provides  alert  messages  containing  the  required  data  in  Comm-A  format  to  the 
client  aircraft.  Also,  when  the  sensor  is  TIS  enabled  it  reads  out  the  contents  of  a  transponder 
Mode  S  extended  capability  register  (GICB  register  16)  during  Mode  S  track  acquisition  and 
provides  a  data  extraction  file  containing  the  tracker  uplink  messages  and  GICB  register 
contents.  The  following  TVRTM  requirements  will  then  be  verified:  7,  77,  83,  170,  242-246, 
259,  308-314,  343, 345  (ote). 
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4,3. 1.2  Testing  Description. 

The  two  FAA  aircraft,  equipped  with  ADLP  and  TIS  displays,  took  off  and  flew  1 0  flight  events 
during  Live  Flight  No.  1.  Although  only  one  aircraft  was  designated  as  the  client,  both  aircraft 
requested  TIS  service  and  recorded  data  for  the  entire  flight. 

See  appendix  B  for  a  complete  description  (and  diagrams)  of  all  live  flights  events.  The  aircraft 
maintained  a  minimum  300-foot  altitude  separation  during  all  maneuvers.  At  one  point  during 
the  flight,  both  aircraft  requested  and  discontinued  TIS  service. 

The  events  completed  in  the  first  flight  included  the  following: 

A.  an  overtaking  intruder  making  a  180°  turn; 

L.  an  overtaking  intruder  making  a  45°  turn; 

K.  both  aircraft  flying  out  of  TIS  and  sensor  coverage,  then  returning; 

I.  the  intruder  overtaking  the  client  on  the  right  side  from  4  miles  out  and  closing  to  within 
1/4  mile  before  turning  to  the  right,  away  from  client  (flown  twice); 

J.  both  aircraft  flew  through  the  zenith  cone  starting  at  least  5  miles  from  the  sensor  (flown 
twice); 

H.  the  intruder  flew  an  S  pattern  overtaking  the  client; 

D.  the  intruder  overtaking  the  client  from  below  on  same  course  and  changing  altitude; 

F.  the  aircraft  flew  on  a  Head-on  course. 

The  Mode  S  sensor  provided  TIS  alert  information  to  the  FAA  aircraft,  maintained  tracks  on  all 
aircraft  within  the  TIS’s  operating  range,  and  recorded  the  Mode  S  data  extractions.  The 
ADLP/TIS  displays  recorded  messages  sent  and  received  by  the  client  aircraft. 


4.3 .1.3  Data  Collection  and  Analysis  Method. 

Data  files  were  collected  at  the  Modes  S  (MTISLIV1.717  and  MTISLIV2.717)  and  on  the 
ADLP/TIS  prototype  displays  (LOGN39a.717,  LOGN39b.717,  LOGN49.717).  The  data  types 
collected  on  the  Mode  S  are  listed  in  section  4.2.2.  The  ADLPs  recorded  Comm  A  messages  that 
were  sent  to  client  aircraft  and  the  Comm  B  messages  that  were  issued  by  the  ADLPs. 

The  RBAT  TIS  Analysis  program  was  used  to  obtain  a  listing  on  the  TIS  client  and  intruder 
aircraft  that  contains  time,  range,  azimuth,  altitude,  ID  codes,  and  track  numbers.  The  DR  TIS 
List  program  was  used  to  list  the  downlink  messages  sent  from  the  TIS  aircraft,  which  show  the 
message  format  and  other  types  of  information.  The  DR  TIS  List  program  also  provided  a  list  of 
the  alert  messages  to  the  TIS  aircraft.  Surveillance  Print,  Miscellaneous  Print  RBAT  programs 
and  the  TIS  Tracker/Alert  analysis  tool  were  used  to  list  the  individual  scan  data  to  determine  the 
flag  bits  that  were  set  or  not  set;  if  TIS  transponder  registers  had  been  read  in  the  correct 
sequence;  and  if  the  selected  data  types  were  correctly  extracted. 
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Detailed  analysis  was  necessary  to  determine  the  cause  of  self-alerts,  incorrect  altitude  values, 
and  what  the  tracker  files  contained  during  the  “crossover  problem.”  The  Surveillance  Print, 
Miscellaneous  Print  RBAT  programs  and  the  TIS  Tracker/Alert  analysis  tool  were  used  to  list 
the  individual  scan  data  to  compare  the  client  Mode  S  report  values  of  azimuth,  range,  altitude, 
and  ID  code  with  the  ATCRBS  report  for  the  TIS  client  ID.  This  detailed  analysis  enabled  the 
test  group  to  determine  that  the  self-alerts  were  caused  by  the  Terra  algorithm  check. 

The  ADLP  display  file  was  played-back  and  the  file  listing  was  reviewed  to  compare  with  the 
Surveillance  Print  results  to  verify  that  the  intruder  aircraft  was  incorrectly  displayed  for  the 
“crossover  problem.” 


4.3. 1.4  Results. 

Review  of  the  data  analysis  results  verified  that  the  sensor  data  link  provided  the  downlink 
request  messages  to  enable  and  disable  TIS  service  to  the  client  aircraft.  When  TIS  is  enabled  on 
the  Mode  S,  local  track  files  are  maintained  for  all  surveillance  targets  (beacon  equipped)  by  TIS 
which  contain  time,  range,  azimuth,  altitude,  ID  codes,  track  numbers,  and  flags.  TIS  tracks  that 
do  not  indicate  a  request  for  TIS  service  are  not  linked  to  a  sector  list  and  do  not  receive  further 
TIS  processing.  ADLP  data  extraction  file  LOGN49.717  and  data  analysis  files 
MPLIV1RP.717,  QLLIV1RP.717,  QLV2RP40.717  were  used  for  requirement  verification. 

Note:  QLHCSPX.723  was  used  to  verify  some  of  the  “altitude_types”  that  did  not  occur  in  the 
live  flight. 

The  TIS  uplink  messages,  which  are  Mode  S  Comm-A’s  (56-bit  format),  were  listed  by  the 
extraction  and  analysis  programs.  Within  the  uplink  messages  the  following  bit  groups  and 
values  have  been  verified:  the  first  8-bits  contain  the  MSP  header  and  has  the  value  02 
hexadecimal  for  all  TIS  messages;  the  next  6  bits  contain  the  message  type  field,  and  the 
remainder  of  the  TIS  uplink  message  contains  two  21 -bit  Traffic  Data  Blocks.  ADLP  data 
extraction  file  LOGN49.717  and  data  analysis  files  TLN39LV1.717,  TLN49LV1.717  were  used 
for  requirement  verification. 

The  TIS  Traffic  Alert  messages  are  composed  of  the  8-bit  MSP  header,  the  6-bit  message  type 
field,  and  two  21 -bit  Traffic  Data  Blocks.  ADLP  data  extraction  file  LOGN49.717  and  data 
analysis  files  TLN39LV1.717,  TLN49LV1.717  were  used  for  requirement  verification. 

During  Mode  S  track  acquisition,  in  which  the  TIS  SAP  is  enabled,  the  contents  of  the 
transponder  Mode  S  extended  capability  register  (GICB  register  16)  were  read  out.  When  the 
MSP  bit  (bit  25  in  the  extended  capability  register)  was  set  (indicating  MSP  avionics  support), 
TIS  set  the  flag  that  read  the  contents  of  the  transponder  MSP  capability  register  (GICB  register 
30)  to  check  whether  the  aircraft  was  requesting  TIS  service.  When  the  flag  was  set,  the  sensor 
requested  this  register  via  a  ground-initiated  Comm-Bs.  Data  analysis  file  QLCMV1RC.718  was 
used  for  requirement  verification,  because  the  correct  sequence  of  evens  did  not  occur  during 
Live  Flight  No.  1. 

When  the  TIS  request  bit  (bit  2)  of  the  MSP  capability  register  was  set  the  TRACK.tis_req_flag 
was  set  TRUE  upon  Mode  S  track  acquisition  and  a  message  containing  the  aircraft's  Mode  S 
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address  and  the  tis_req  flag  value  was  sent  to  Data  Extraction.  Data  analysis  files 
QLCMV1SF.718  and  QLLIV31.717  were  used  for  requirement  verification. 

When  the  MSP  bit  was  not  set,  or  when  the  TIS  request  bit  was  not  set,  then  the 
TRACK.tis_req_flag  was  set  FALSE  at  Mode  S  track  acquisition  and  TIS  was  not  provided  to 
that  aircraft.  ADLP  data  extraction  file  LOGN49.717  and  data  analysis  file  QLLV2312.717 
were  used  for  requirement  verification. 

When  the  sensor  received  a  broadcast  downlink  message,  it  checked  for  a  TIS  Mode  S-Specific 
Protocol  message.  The  first  8  bits  were  examined  to  see  if  the  value  was  02  hexadecimal,  that 
value  identified  a  TIS  Service  Connect  Request  (TSCR)  or  a  TIS  Service  Disconnect  Request 
(TSDR)  was  in  the  Comm  B  messages.  Data  analysis  files  MPLIV191.717,  SPLIVGA.717, 
TN49LIV2.717,  and  ADLP  data  extraction  file  LOGN49.717  were  used  for  requirement 
verification. 

When  the  restart  was  the  result  of  a  sensor  channel  switch,  the  track  file  was  initialized  and 
forced  the  generation  of  a  goodbye  message  to  all  the  TIS-requesting  aircraft.  ADLP  data 
extraction  file  LOGN49a.718  was  used  for  requirement  verification.  The  Mode  S  channel  switch 
occurred  during  Live  Flight  No.  2. 

Analysis  printouts  were  used  to  verify  that  the  following  categories  were  extracted  for  TIS:  TIS 
reports  that  are  used  as  inputs  to  update  the  TIS  track  file;  TIS  track  file  entries  that  are  updated 
by  the  tracking  task;  TIS  alerts/messages  that  were  uplinked  to  the  TIS  requesting  aircraft; 
requests  that  initiated  TIS  service  via  TSCR  downlinks;  requests  that  terminated  TIS  service  via 
TSDR  downlinks;  and  acquisition  of  aircraft  requesting  TIS  service  via  the  readout  of  the 
transponder  GICB  registers.  Data  analysis  files  MPLIVrp.717,  TN49LIV2.717,  MPLIV191.717, 
SPLIVGA.717,  QLCMV1RC.718,  and  ADLP  data  extraction  file  LOGN49.717  were  used  for 
requirement  verification. 

The  following  TIS  requirements  were  verified  as  a  result  of  observations  and  data  analysis  on  the 
data  extractions  during  the  Live  Flight  No.  1:  7, 77,  83,  170, 242-246, 259, 308-314, 343,  345. 


4,3. 1.5  Discussion. 

This  section  includes  issues  of  concern  and  the  status  of  each  of  these  items: 


4.3 .1.5.1  Self-Alerts 

Self- Alerts  occurred  when  the  TIS  mistakenly  identified  the  client's  own  aircraft  as  an  intruder 
and  sent  an  alert  message.  The  self-alerts  are  shown  as  “False  Alarms”  in  the  following  list  of 
results: 
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Test  Mode  S  - Traffic  Advisory -  - Proximity  Advisory — 

Number  DE  File  Size  Rel  Size  FAlrm  Size  Rel  Size  FAlrm 

Flt#l  mtislivl .717  28  100.0  37  24.3  386  100.0  386  0.0 

Flt#l  mtisliv2 . 717  315  100.0  338  6.8  1095  99.9  1094  0.0 

Detailed  analysis  of  the  data  extraction  (DE)  files  (MTISLIV1 .717  and  MTISLIV2.717)  and 
ADLP  log  files  (LOGN39a.717,  LOGN39b.717,  LOGN49.717)  indicate  that  some  type  of 
surveillance  error  occurred  at  the  same  timeframe  as  the  self-alerts.  The  surveillance  errors 
included: 

a.  Altitude  differences  between  client  Mode  S  and  ATCRBS  reports  occurred  1 6  times. 

b.  Range  differences  between  client  Mode  S  and  ATCRBS  reports  occurred  six  times. 

c.  Garbled  ATCRBS  IDs  occurred  two  times. 

d.  In  one  case,  the  ATCRBS  altitude  exceeded  65,00  feet  which  is  an  invalid  value  for 
normal  Mode  S  operation. 

The  self-alerts  that  occurred  during  DE  MTISLIV1.717  are  identified  in  excerpts  from  the  TIS 
analysis  files  TSN39LV1.717  and  TSN49LV1 .717  which  are  listed  below.  A  description  of  the 
results  listed  is  shown  in  appendix  D. 
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The  self-alerts  occurred  between  13:26:20  and  13:27:15,  when  the  FAA  aircraft  (N39  &  N49) 
were  taking  off  from  the  Technical  Center.  The  aircraft  were  on  the  same  radial  from  the  Mode 
S  sensor  with  N39  (ID  0140)  ahead  of  N49  (ID  0141).  Eight  of  the  nine  alerts  occurred  to  N39 
as  the  aircraft  climbed  from  900  feet  to  1900  feet  in  less  than  a  minute.  N49  was  climbing  from 
200  feet  to  1300  feet  during  the  same  period  and  was  between  N39  and  the  Mode  S  sensor.  All 
of  the  alerts  occurred  during  the  time  while  both  aircraft  were  on  the  same  radial.  Once  N39 
turned  to  the  left,  the  alerts  ended.  Five  garbled  ranges  and  three  garbled  altitudes  on  the 
ATCRBS  ID  0140  caused  the  alerts  and  the  one  self-alert  on  N49  was  the  invalid  altitude  of 
62,500  feet  on  ID  0141. 

Additional  self-alerts  occurred  during  DE  MTISLIV2.717.  They  are  identified  in  excerpts  from 
the  TIS  analysis  files  TSN39LV2.717  and  TSN49LV2.717  which  are  listed  below.  A  description 
of  the  results  listed  is  shown  in  appendix  D. 
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e.  The  first  occurrence  was  during  Event  I  at  14:01 :37  to  14:01 :46  and  a  range  of  49  nmi. 

As  N49  (the  intruder),  closed  on  N39  (the  client),  the  self-alerts  occurred  on  N49  when  it 
was  turning  to  fly  parallel  to  N39.  There  were  three  garbled  altitudes  and  one  garbled  ID 
on  ATCRBS  ID  0141  (N49). 

f.  The  second  occurrence  was  during  Event  I  at  14: 1 0:32  to  1 4: 1 0:46  and  a  range  of  22  nmi. 
The  self-alerts  occurred  when  N49  closed  on  N39  and  made  a  turn  to  fly  parallel  to  N39. 
This  time  the  alerts  were  on  N39  (ID  0140)  and  there  were  four  garbled  altitude  values. 

g.  The  third  occurrence  was  a  self-alert  onN39  (ID  0140)  at  14:13:51,  a  garbled  altitude 
value,  but  there  was  no  event  in  progress  at  this  time. 

h.  The  fourth  occurrence  was  a  self-alert  on  N39  (ID  0140)  at  14:20:35  as  the  aircraft  was 
making  a  turn  to  start  a  new  event.  The  aircraft  antenna  turning  away  from  the  sensor 
antenna  during  this  scan  may  have  caused  a  garbled  altitude  on  ID  0140. 

i.  The  fifth  occurrence  was  at  14:34:00  on  N39.  A  garbled  altitude  on  ID  0140  caused  the 
self-alert  and  no  event  was  in  progress. 

j.  The  sixth  occurrence  was  at  14:35:46  during  Event  D.  Both  aircraft  were  on  the  same 
radial  from  sensor  with  N49  directly  under  N39  and  climbing  at  the  time  the  self-alert 
occurred  on  N39.  A  garbled  altitude  on  ID  0140  may  have  been  caused  by  N49  blocking 
the  signal  back  to  the  sensor  antenna. 

k.  The  seventh  occurrence  was  self-alerts  on  N49  at  14:38:00  and  14:38:05.  The  aircraft 
were  flying  away  from  the  sensor  on  the  same  radial.  No  event  was  in  progress  at  this 
time.  The  first  self-alert  was  a  result  of  garbled  altitude  and  ID  split  of  ID  0141.  The 
second  self-alert,  a  garbled  range  value  on  the  ID  0141. 

l.  The  eighth  occurrence  was  on  N39  at  14:44:37  during  Event  F  when  N49  was  passing 
under  N39.  The  altitude  value  for  ID  0140  (N39)  was  garbled  for  this  scan. 


These  errors  in  the  ATCRBS  reports  and  the  self-alerts  that  are  generated  by  TIS,  are  a  result  of 
the  "Terra  check."  The  "Terra  fix"  was  implemented  to  detect  defective  transponders 
manufactured  by  the  Terra  Corporation.  In  "Terra"  mode,  both  a  Mode  S  and  ATCRBS  track  are 
generated  for  each  Mode  S  target.  Occasionally,  when  garbling  or  poor  detection  has  occurred, 
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TIS  mistakenly  identifies  this  ATCRBS  track  as  an  intruder  (to  the  client  Mode  S  track),  and 
sends  an  advisory  message  to  the  client,  which  is  shown  on  the  TIS  display  as  being  directly  on 
top  of  the  client.  This  additional  ATCRBS  target  report,  resulting  from  the  garbling  condition,  is 
also  part  of  the  normal  ATC  disseminated  surveillance  data. 

The  test  group  did  not  generate  any  new  SPR’s  against  the  “self-alert”  problem  because  it  is  a 
known  problem  (from  the  1995  TIS  Demo).  The  following  three  SPRs  are  still  open  awaiting 
resolution: 

SPR  #54  3/14/95  Self-alerts, 

SPR  #107  Traffic  advisory  false  alarm  rate  high  for  scenarios  and  live  flights, 

SPR  #117  Self-alerts  still  occur  due  to  the  “Terra  fix”  in  Mode  S  software. 


4.3.1.5.2  Altitude  Anomaly. 

The  Altitude  Anomaly  problem  has  been  identified  in  other  Mode  S  data  collections  and  during 
the  TIS  testing  conducted  in  1995.  There  was  one  occurrence  during  the  Live  Flight  No.  1  test  at 
13:27:15.  The  Mode  S  falsely  reported  the  client  aircraft's  altitude  at  some  extremely  large  value 
(i.e.,  65,200  feet)  for  two  scans,  and  then  returned  it  back  to  normal  for  the  following  scans.  This 
inaccurate  reporting  of  the  altitude  for  an  ATCRBS  ID  resulted  in  the  TIS  generating  a  self-alert 
on  the  ADLP  TIS  display.  This  is  a  Mode  S  altitude  detection  problem  and  is  not  specific  to  TIS. 
The  invalid  altitudes  were  also  found  to  occur  during  the  ARIES  scenario  tests. 

The  test  group  did  not  generate  any  new  SPR’s  against  the  “altitude  anomoly”  because  it  is  a 
known  problem  (from  1995  TIS  Demo)  and  the  following  two  SPRs  are  still  open  awaiting 
resolution: 

SPR  #89  Garbled  altitude  data  is  reported  with  high  altitude  confidence  within  the 

Mode  S  Surveillance  tracking  (PTR  04285085V  became  TE00.1  SPR  GV95- 
15204), 

SPR  #118  Invalid  altitudes  cause  numerous  problems  with  TIS  and  surveillance. 


4.3. 1.5.3  Tracking  Anomaly. 

The  TIS  Tracking  Anomaly  problem  was  observed  on  the  ADLP  during  Live  Flight  No.  1, 
within  30  nmi  range,  when  a  fast  maneuvering  intruding  target  flew  very  close  to  the  client 
aircraft.  This  problem  was  initially  observed  during  a  flight  test  of  the  TIS  OT&E  for  the  Dulles 
demo  in  1995  and  is  referred  to  as  the  "crossover  problem."  This  event  (I)  was  conducted  two 
times  during  the  Live  Flight  No.  1 ,  once  at  a  range  of  approximately  50  nmi  and  at  a  range  of 
approximately  22  nmi. 

At  the  50  nmi  range,  the  TIS  software  overlays  the  intruder  onto  the  client  on  the  ADLP  for  the 
six  scans  (14:01 :23  to  14:01 :46)  when  the  tracker  data  crosses  over  to  the  left  side  of  the  client. 

At  the  22  nmi  range,  the  TIS  software  displays  the  intruder  crossing  to  the  rear  of  the  client  and 
then  moving  along  side.  The  intruder  is  displayed  to  the  right  of  the  client  for  five  scans 
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(14:10:37  to  14:10:55)  and  then  jumps  to  the  left  side  of  the  client.  The  problem  has  been 
identified  to  Massachusetts  Institute  of  Technology  Lincoln  Laboratories  (MITLL).  After 
reviewing  the  problem,  MITLL  has  stated  that  it  cannot  be  corrected  due  to  the  tracker  algorithm 
design  and  the  scan  update  rate  of  4  to  5  seconds  for  the  Terminal  Mode  S  system. 

The  test  group  did  not  generate  any  new  SPRs  against  the  “crossover  problem”  because  it  is  a 
known  problem  (from  1995  TIS  Demo)  and  the  following  two  SPRs  are  still  open  awaiting 
resolution: 

SPR  #71  3/16/95  Crossover  Retry  Shows  N35  on  Wrong  Side  of  N50, 

SPR#119  Crossover  fix  didn’t  work. 

NOTE:  These  two  SPRs  relate  to  flight  maneuvers  at  less  than  35  nmi. 


4.3 .1.6  Conclusions. 

All  the  aircraft  events/maneuvers  from  Live  Flight  No.  1  were  completed  and  the  test  results  are 
good.  All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  After  all  the 
detailed  analysis  was  completed,  no  major  problems  were  found,  although  three  minor  problems 
have  been  identified. 


4.3.1 .6.1  Self-Alerts. 

This  problem  occasionally  occurred  during  the  live  flight  data  collections,  just  as  it  had  during 
the  scenario  test  runs.  Detailed  analysis  of  each  of  the  problem  test  cases  indicate  that  there  was 
some  type  of  Mode  S  surveillance  problem  or  failure  when  this  problem  occurred  (i.e.,  garbled 
ATCRBS  IDs,  garbled  altitude  values,  missing  ATCRBS  reports).  The  primary  cause  of  these 
self-alerts  is  the  Mode  S  sensor  "Terra  fix."  Until  the  removal  of  the  “Terra  fix”  is  complete,  this 
will  continue  to  be  a  problem. 


4.3. 1.6.2  TIS  Tracking  Anomaly. 

Again,  as  in  the  scenario  testing  and  the  1995  TIS  Dulles  Demo,  the  live  flight  "crossover" 
maneuver  created  the  intruder  crossover  problem  on  the  TIS  display.  The  intruder  aircraft  is 
displayed  incorrectly  as  a  result  of  the  limitations  of  the  TIS  tracking  algorithm.  This  “crossover 
problem”  must  be  identified  to  the  General  Aviation  Pilots  since  it  cannot  be  corrected.  ACT- 
310  has  been  notified  that  there  is  a  change  to  the  Aeronautical  Information  Manual  (AIM)  in 
progress  that  will  include  information  on  the  crossover  display  problem.  This  change  is 
necessary  before  TIS  can  be  released  to  the  field  for  public  use. 


4.3 . 1 .6.3  Altitude  Anomaly. 

One  minor  problem  that  occurred  during  the  flight  testing  was  a  Mode  S  altitude  detection 
problem,  which  was  not  specific  to  TIS.  Occasionally,  for  some  unexplained  reason,  the  Mode  S 
would  falsely  report  an  aircraft's  altitude  at  some  extremely  large  value  (i.e.,  67,000  feet)  for  one 
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scan,  and  then  return  it  back  to  normal  the  following  scans.  However,  this  inaccurate  reporting 
of  altitude  for  ATCRBS  targets  did  result  in  TIS  misplotting  intruders  on  the  ADLP/TIS  display. 
The  invalid  altitudes  were  also  found  to  occur  with  the  current  Mode  S  fielded  baseline  software 
image  and  with  the  ARIES  scenarios. 


4.3.2  TEST:  Live  World  Flight  No.  2. 


4.3.2. 1  Test  Obi ecti ve/Criteria. 

The  objective  of  this  test  is  to  verily  that  the  input  Mode  S  track  is  checked  to  see  if  it  is 
currently  receiving  TIS.  If  it  received  TIS  on  previous  scans,  and  is  flagged  as  not  receiving  TIS 
currently,  then  set  the  appropriate  flags.  Verify  that  “keep-alive”  messages  for  a  track  are 
generated  when  TIS  service  is  requested,  after  the  third  update  and  when  a  channel  switch  has 
occurred;  that  if  the  aircraft  receiving  TIS  has  flown  into  the  zenith  cone,  then  a  “goodbye” 
message' is  sent;  and  that  alert  messages  containing  the  required  data  are  in  Comm- A  format  as 
they  are  sent  to  the  client  aircraft.  Also,  that  the  TIS  Comm-B  message  containing  the 
Application  Identifier  Numbers  is  read,  the  correct  flags  are  set,  and  that  the  downlink  message 
is  sent  to  Data  Extraction  for  analysis.  The  following  TVRTM  requirements  will  then  be 
verified:  109-111, 115, 116,  129,  142,  170,  242-246,  259,  298,  315-321,  321.5  (ote). 


4.3.2.2  Testing  Description. 

The  two  FAA  aircraft,  equipped  with  TIS  transponders  and  ADLP,  took  off  and  flew  five  flight 
events  during  Live  Flight  No.  2.  See  appendix  B  for  a  complete  description  (and  diagrams)  of  all 
live  flights  events.  The  aircraft  maintained  a  minimum  300-foot  altitude  separation  during  all 
maneuvers.  At  some  point  during  the  flight,  the  aircraft  requested  and  discontinued  TIS  service. 

The  events  (maneuvers)  for  the  second  flight  included  the  following: 

B.  the  intruder  making  a  90°  crossing  pattern  behind  the  client; 

C.  the  intruder  making  a  90°  crossing  pattern  ahead  of  the  client; 

E.  at  a  location  25  miles  from  sensor,  the  client  started  an  arc  around  the  sensor  and  then  the 
intruder  flew  across  the  arc; 

G.  at  a  location  25  miles  from  sensor,  the  client  started  an  arc  around  the  sensor  and  then  the 
intruder  flew  on  the  same  arc  overtaking  the  client. 

X.  the  intruder  flew  directly  behind  the  client  in  a  straight  line,  starting  one-half  mile  apart. 
Intruder  slows  down  increasing  distance  between  aircraft  to  3  miles,  then  gradually  increase 
speed  to  close  the  gap  to  within  1  mile. 

NOTE:  Event  X  was  designed  at  the  pilot  briefing  meeting  on  July  1 8,  1997,  to  verify  that  the 
intruder  position  on  the  ADLP  was  corrected. 
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} 


The  Mode  S  sensor  provided  TIS  alert  information  to  the  FAA  aircraft,  maintained  tracks  on  all 
aircraft  within  the  TIS’s  operating  range,  and  recorded  the  Mode  S  data  extractions.  The 
ADLP/TIS  displays  recorded  messages  sent  and  received  by  the  client  aircraft.  A  Mode  S  sensor 
channel  switch  was  conducted  to  create  a  restart  of  the  system  and  generation  of  goodbye 
messages  to  all  aircraft  receiving  TIS  service. 


4.3. 2.3  Data  Collection  and  Analysis  Method. 

Data  files  were  collected  at  the  Modes  S  (MTISLIV1.718,  MTISLIV2.718,  MTISLIV3.718)  and 
on  the  ADLP  (LOGN39.71R.  LOGN49a.718,  LOGN49b.718).  The  data  types  collected  on  the 
Mode  S  are  listed  in  section  4.2.2  The  ADLP/TIS  prototype  displays  recorded  uplink  messages 
that  were  sent  to  and  downlink  messages  that  were  issued. 

The  RBAT  TIS  Analysis  program  was  used  to  obtain  target  listing  of  TIS  aircraft  which  contain 
time,  range,  azimuth,  altitude,  ID  codes,  and  track  numbers.  The  DR  TIS  List  program  was  used 
to  list  the  downlink  messages  sent  from  the  TIS  aircraft  that  contain  flags  and  other  types  of 
information.  Surveillance  Print  and  Miscellaneous  Print  RBAT  programs,  and  the  TIS 
Tracker/Alert  analysis  tool  were  used  for  detailed  analysis  of  the  test  data. 


4.3 .2.4  Results. 

Review  of  the  data  analysis  results  verified  that  when  the  input  Mode  S  track  is  not  flagged  as 
currently  receiving  TIS,  the  input  handler  checks  whether  it  was  flagged  for  receiving  TIS  on  the 
previous  update.  If  the  input  Mode  S  track  was  flagged  for  receiving  TIS  on  the  previous  update, 
and  a  "goodbye"  message  was  already  sent  to  the  aircraft  being  processed  (as  indicated  by  a  flag 
in  the  TIS  track  file  entry),  the  processing  removes  the  track  being  processed  from  its  sector  lists 
and  the  number  of  TIS-requesting  aircraft  is  decremented.  ADLP  data  extraction  file 
LOGN49a.718  and  data  analysis  files  TNL49LV1.718,  MPLIV1RQ.718,  QLLIV1 10.718  were  ^ 
used  for  requirement  verification.  Note:  “the  number  of  TIS-requesting  aircraft  is  decremented” 
operation  was  verified  in  requirement  106. 

When  the  input  Mode  S  track  is  not  flagged  as  currently  receiving  TIS  and  the  "goodbye" 
message  was  not  sent,  the  flag  in  the  TIS  track  is  set  to  indicate  that  a  "goodbye"  message  should 
be  sent  immediately.  Data  analysis  files  MPLIV20C.717,  QLOCLV2.717,  and 
QLOCLV2A.717  were  used  for  requirement  verification.  The  out-of-coverage  occurred  during 
Live  Flight  No.  1. 

When  the  input  Mode  S  track  update  or  coast  is  flagged  as  currently  receiving  TIS  service,  a 
check  was  performed  to  determine  if  the  Mode  S  aircraft  had  flown  into  the  zenith  cone  using  the 
precomputed  TIS  zenith  cone  table.  When  the  aircraft  receiving  TIS  service  flies  into  the  zenith 
cone  a  "goodbye"  message  was  sent.  Data  analysis  files  MPLIV2.717  and  QL89LV2.717  were 
used  for  requirement  verification.  The  Zenith  Cone  out-of-coverage  occurred  during  Live  Flight 
No.  1. 

When  the  Mode  S  channel  switch  occurred,  and  the  TIS  track  was  flagged  for  TIS  service,  a 
“goodbye”  message  was  generated  for  uplink  to  aircraft  while  the  sensor  TIS  software  was 
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reinitializing  and  the  horizontal  track  state  was  FIRST.  ADLP  data  extraction  file 
LOGN49a.718  was  used  for  requirement  verification.  The  horizontal  track  state  of  FIRST  could 
not  be  shown  because  the  data  extraction  stopped  during  the  channel  switch,  but  the  “goodbye” 
message  was  sent  so  it  is  assumed  that  the  software  worked  as  described. 

When  the  TIS  tracker  requesting  TIS  service  had  its  third  update  and  a  sensor  channel  switch 
occurs,  the  track  is  flagged  and  a  “keep-alive”  message  is  generated.  ADLP  data  extraction 
LOGN49a.718  was  used  for  requirement  verification.  The  “third  update”  could  not  b«  shown 
because  the  data  extraction  stopped  during  the  channel  switch,  but  the  “keep-alive’  message  was 
sent  so  it  is  assumed  that  the  software  worked  as  described. 

TIS  tracks  that  do  not  indicate  a  request  for  TIS  service  a**  sot  linked  to  a  sector  list  and  do  not 
receive  further  TIS  processing.  ADLP  data  extrachon  file  LOGN49a.718  and  data  analysis  files 
TNL49LV1.718,  MPLIV1RQ.718,  QLLIV1 10.718  were  used  for  requirement  verification. 

The  TIS  uplink  messages,  which  are  Mode  S  Comm-A’s  (56-bit  format),  were  listed  by  the 
analysis  programs.  Within  the  uplink  messages,  the  following  bit  groups  and  values  have  been 
verified:  the  first  8  bits  contain  the  MSP  header  and  has  the  value  02  hexadecimal  for  all  TIS 
messages;  the  next  6  bits  contain  the  message  type  field,  and  the  remainder  of  the  TIS  uplink 
message  contains  two  21 -bit  Traffic  Data  Blocks.  ADLP  data  extraction  file  LOGN49a.718  and 
data  analysis  files  TLN39LV1.718,  TLN49LV1.718  were  used  for  requirement  verification. 

The  TIS  Traffic  Alert  messages  are  composed  of  the  8-bit  MSP  header,  the  6-bit  message  type 
field,  and  two  21-bit  Traffic  Data  Blocks.  ADLP  data  extraction  file  LOGN49a.718  and  data 
analysis  files  TLN39LV1.718,  TLN49LV1.718  were  used  for  requirement  verification. 

The  following  values  were  verified  with  data  analysis  printouts:  Eight-bit  Application  Identifier 
Numbers  (AINj,  j=l  to  6)  are  read  from  the  TIS  Comm  B  message  (TSCR  or  TSDR)  until  either 
of  the  following  occurred:  first,  AINj  =  0  or  second,  all  56  bits  of  the  downlink  message  were 
processed.  A  request  for  TIS  service  (TSCR)  was  identified  by  an  AIN  value  of  1 .  A  request  to 
terminate  TIS  service  (TSDR)  was  identified  by  an  AIN  value  of  2.  ADLP  data  extraction  file 
LOGN49a.718  and  data  analysis  files  TLN39LV1.718,  TLN49LV1.718  were  used  for 
requirement  verification. 

When  the  downlink  was  a  TSCR,  then  the  TRACK.tis_req_flag  was  set  TRUE  and  a  message 
was  sent  to  Data  Extraction  containing  the  aircraft's  Mode  S  address  and  the  value  of 
TRACK.tis_req_flag .  ADLP  data  extraction  file  LOGN49a.718  and  data  analysis  files 
MPLIV1RQ.718,  QLLV1 1101 .718  were  used  for  requirement  verification. 

When  the  downlink  was  a  TSDR,  then  the  TRACK.tis_req_flag  was  set  F ALSE  and  a  message 
was  sent  to  Data  Extraction  containing  the  aircraft's  Mode  S  address  and  the  value  of  FALSE 
indicating  that  TIS  service  was  being  discontinued  to  the  aircraft  being  processed.  ADLP  data 
extraction  file  LOGN49a.718  and  data  analysis  files  MPLIV1RQ.718,  QLLV11101.718  were 
used  for  requirement  verification. 
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When  the  SAP  to  enable  TIS  was  set,  the  first  interrogation  to  an  aircraft  on  each  scan  did  not 
include  any  Comm-A  messages.  ADLP  data  extraction  files  LOGN39.718,  LOGN49a.718,  and 
data  analysis  files  TLN39LV1.718,  TLN49LV1.718  were  used  for  requirement  verification. 

These  TIS  requirements  were  verified  as  a  result  of  observations  and  data  analysis  on  the  data 
extractions  during  the  Live  Flight  No.  2: 109-1 11, 115, 116, 129, 142, 170, 242-246, 259, 298, 
315-321,321.5. 

Event  X:  It  was  determined  during  Live  Flight  No.  1  that  the  intruders  were  not  being  displayed 
correctly  on  the  prototype  TIS  display  screens.  Discussion  with  technical  support  personnel  at 
MITLL  and  ACT-350  agreed  with  the  test  group’s  observations.  ACT-350  was  able  to  make  a 
change  to  TIS  display  software  on  the  intruder  aircraft  (N49).  In  event  X,  the  aircraft  flew  in  a 
straight  line  with  the  lower  aircraft  (N49)  overtaking  the  upper  aircraft  (N39)  until  ahead  and 
then  slowing  in  speed  allowing  the  upper  aircraft  (N3  9)  to  overtake  (N49).  The  ADLP  operator 
in  N49  observed  that  N39  always  appeared  in  the  correct  reference  to  N49.  Testing  of  the  ADLP 
software  was  not  part  of  the  requirements  to  be  verified  during  current  TIS  testing.  The  ADLPs 
provided  the  test  group  a  means  to  conduct  a  complete  end-to-end  system  test.  The  ADLP 
hardware  and  software  will  have  to  be  formally  tested  at  a  later  time. 


4.3. 2.5  Discussion. 

This  section  includes  issues  of  concern  and  the  status  of  each  of  these  items: 

4.3 .2.5.1  Self-Alerts. 

Self-Alerts  also  occurred  during  Live  Flight  No.  2.  The  self-alerts  are  shown  as  “False  Alarms” 
in  the  following  list  of  results: 


Test 

Mode  S 

- Traffic 

Advisory - 

- Proximity 

Advisory — 

Number 

DE  File 

Size 

Rel 

Size  FAlrm 

Size 

Rel 

Size 

FAlrm 

Flt#2 

mtislivl .718 

117 

99.1 

135  14.1 

1305 

99.2 

1295 

0.0 

Flt#2 

mtisliv2 . 718 

0 

0 

5 

100.0 

5 

0.0 

Flt#2 

mtisliv3 . 718 

0 

0 

69 

98.6 

68 

0.0 

Detailed  analysis  of  the  data  extraction  (DE)  files  (MTISLIV1.718,  MTISLIV2.718, 
MTISLIV3.718)  and  ADLP  log  files  (LOGN39.718,  LOGN49a.718,  LOGN49b.718)  indicate 
that  some  type  of  surveillance  error  occurred  at  the  same  timeframe  as  the  self-alerts.  The 
surveillance  errors  included: 

a.  Altitude  differences  between  client  Mode  S  and  ATCRBS  reports  occurred  eight  times. 

b.  Range  differences  between  client  Mode  S  and  ATCRBS  reports  occurred  eight  times. 

c.  Garbled  ATCRBS  IDs  occurred  12  times. 

The  self-alerts  that  occurred  during  DE  MTISLIV1.71  analysis  files  TSN39LV1.718  and 
TSN49LV1.718  are  listed  below.  A  description  of  the  results  listed  is  shown  in  appendix  D. 
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Time-Of-Day  Range  Azmth 

Alt 

Head  TisHd  Mds-Id 

SFN 

T 

M 

Id 

SFN 

10:08:18.711 

23.7 

222.5 

6900 

138.5 

153.0 

a4806f 

627 

N 

T 

0256 

166 

10:09:18.688 

24.2 

214.4 

6600 

137.9 

153.0 

a4806f 

627 

N 

T 

0256 

166 

10:10:23.250 

25.4 

206.2 

6900 

153.0 

a4806f 

627 

N 

T 

0256 

166 

10:35:01.438 

31.8 

253.5 

6300 

183.0 

ac9451 

227 

N 

T 

0257 

184 

10:35:06.047 

31.8 

253.2 

6300 

183.0 

ac9451 

227 

N 

T 

0257 

184 

10:44:34.664 

36.1 

281.4 

6300 

269.9 

315.0 

ac9451 

227 

N 

T 

0257 

184 

10:44:39.289 

36.3 

281.4 

6300 

258.5 

309.0 

ac9451 

227 

N 

T 

0257 

184 

10:45:20.852 

37.4 

280.0 

6600 

193.3 

201.0 

a4806f 

627 

N 

T 

0256 

166 

10:45:57.758 

36.9 

277.1 

6600 

145.6 

177.0 

a4806f 

627 

N 

T 

0256 

166 

10:46:02.375 

36.7 

276.8 

6600 

142.4 

177.0 

a4806f 

627 

N 

T 

0256 

166 

10:46:30.055 

35.6 

275.2 

6900 

137.1 

153.0 

a4806f 

627 

N 

T 

0256 

166 

10:46:34.672 

35.4 

275.0 

6900 

137.5 

153.0 

a4806f 

627 

N 

T 

0256 

166 

10:50:11.469 

35.2 

251.6 

6900 

165.2 

183.0 

a4806f 

627 

N 

T 

0256 

166 

10:50:16.078 

35.3 

251.0 

6900 

164.2 

183.0 

a4806f 

627 

N 

T 

0256 

166 

10:50:16.086 

35.2 

251.6 

6300 

163.6 

177.0 

ac9451 

227 

N 

T 

0257 

184 

10:55:29.898 

26.1 

224.0 

6200 

72.1 

87.0 

ac9451 

227 

N 

T  • 

0257 

184 

10:55:34.523 

25.9 

223.7 

6200 

71.9 

87.0 

ac9451 

227 

N 

T 

0257 

184 

The  following  text  gives  the  specific  times  and  ATCRBS  deficiencies  when  the  self-alerts 

occurred  during  DE  file  MTISLIV1.718. 

d.  The  first  occurrence  was  during  Event  B  at  10:08:37,  a  self-alert  on  N39  (ID  0256),  caused 
by  a  garbled  altitude  on  ID  0256.  A  self-alert  on  N39  at  10:09: 1 8,  another  garbled  altitude 
on  ID  0256  and  another  alert  at  10:10:23  on  N39  because  of  a  garbled  altitude.  None  of  the 
alerts  can  be  associated  to  the  maneuvers  of  the  event. 

e.  The  second  occurrence  was  at  10:35:01  and  10:35:06  on  N49  (ID  0257).  The  first  alert  was  a 
garbled  ID  (0257)  and  garbled  range.  The  second  was  a  garbled  range  difference  between 
the  Mode  S  and  ACTRBS  reports.  There  was  another  aircraft  close  to  N49  and  may  have 
caused  the  garbled  reports. 

f.  The  third  occurrence  was  during  Event  G  at  10:44:34  and  10:44:39  on  N49  (ID  0257).  N49 
was  making  a  turn  away  from  sensor  when  alerts  occurred  and  the  antenna  may  have  been 
blocked.  The  ATCRBS  reports  had  a  garbled  ID  and  range,  then  a  garbled  ID,  range,  and 
altitude. 

g.  The  fourth  occurrence  was  alerts  on  N39  during  Event  G  (reverse  direction).  The  alerts 
occurred  at  10:45:20,  10:45:57, 10:46:02, 10:46:30,  and  10:46:34  as  the  aircraft  was 
overtaking  N49.  The  two  aircraft  were  not  in  close  proximity  to  each  other  so  the  ID  0257 
ATCRBS  report  had  errors  of  garbled  ID,  range,  altitude  and  are  unrelated  to  event 
maneuvers. 

h.  The  fifth  occurrence  was  at  14:34:00  on  N39.  A  garbled  altitude  on  ID  0140  caused  the  self¬ 
alert  and  no  event  was  in  progress. 

i.  The  sixth  occurrence  was  also  during  Event  G.  The  alerts  occurred  at  10:50:1 1  and  10:50:16 
when  N39  was  passing  over  N49.  The  alert  was  caused  by  garbled  altitude  for  N39  (ID 
0256)  at  10:50:1 1  and  a  split  occurred  from  ID  0257.  The  alerts  at  10:50:16  were  a  result  of 
a  garbled  range  for  ID  0257  and  an  ID  split  for  0256. 
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j.  The  seventh  occurrence  was  self-alerts  on  N49  at  10:55:29  and  10:55:34.  The  aircraft  were 
flying  toward  the  sensor  when  the  alerts  were  sent.  The  first  self-alert  was  a  result  of  a 
garbled  ID  and  garbled  range.  The  second  alert  was  a  result  of  a  garbled  range  on  ATCRBS 
ID  0257. 


4.3.2.6  Conclusions. 

All  the  aircraft  events/maneuvers  from  Live  Flight  No.  2  were  completed  and  the  test  results  are 
good.  All  TIS  requirements  associated  with  this  test  have  been  completely  verified.  After  all  the 
detailed  analysis  was  completed,  no  major  problems  were  found,  and  only  one  minor  problem 
was  identified. 

4.3 .2.6.1  Self-Alerts. 

This  problem  occasionally  occurred  during  the  live  flight  data  collections,  just  as  it  had  during 
the  scenario  test  runs.  Detailed  analysis  of  each  of  the  problem  test  cases  indicate  that  there  was 
some  type  of  Mode  S  surveillance  problem  or  failure  when  this  anomaly  occurred  (i.e.,  garbled 
ATCRBS  IDs,  garbled  altitude  values,  missing  ATCRBS  reports).  The  primary  cause  of  these 
self-alerts  is  the  Mode  S  sensor  "Terra  fix."  Until  the  removal  of  the  “Terra  fix”  is  complete,  this 
will  continue  to  be  a  problem. 
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4.4  TEST:  REGRESSION  TESTING. 


The  Regression  Testing  focused  primarily  on  verification  of  existing  Mode  S  requirements  (from 
Specification  FAA-E-2716)  and  that  introduction  of  TIS  into  the  Mode  S  baseline  did  not 
degrade  performance,  nor  have  any  negative  side  effects.  The  Regression  testing  was  conducted 
using  the  Mode  S  Release  Qualification  Test  (RQT)  procedure.  The  RQT  consisted  of  the 
following: 

a.  RQT  Configuration  Review  (RCR):  Prior  to  the  start  of  the  RQT,  a  pretest  meeting  was 
held.  At  this  meeting,  the  test  hardware/software  configuration  was  presented,  the  test 
team  roles  and  responsibilities  were  defined,  and  the  pretest  issues  were  discussed. 

b.  General  Tests:  The  general  test  was  the  part  of  the  RQT  that  verified  the  new 
hardware/software  baseline.  The  RQT  general  tests  included  portions  that  tested  a  wide 
variety  of  Mode  S  Sensor  functions  such  as;  sensor  control,  initialization/recovery,  sensor 
status,  target  handling  capacity,  sensor  stability,  and  interfaces. 

c.  Special  Tests:  This  test  was  written  specific  to  this  software  release,  and  targeted  specific 
software  changes  to  prove  the  new  functionality.  A  special  test  case  to  test  TIS 
transponder  Register  29  was  conducted  during  the  RQT. 


The  RQT  and  regression  testing  of  TIS  register  29  was  conducted  using  SAR214.F  image  and 
TISZCONE  image  on  September  22,  1997,  at  the  Technical  Center  in  Atlantic  City,  NJ. 

ACT-3 10  staff  along  with  contractor  personnel  conducted  the  tests.  The  following  tasks: 
operating  the  Mode  S  sensor,  operation  of  the  GA  transponder,  collecting  and  analyzing  data 
were  completed  by  the  test  group. 


4.4.1  Test  Obi ective/Criteria. 

To  successfully  verify  that  introduction  of  TIS  into  the  Mode  S  baseline  does  not  degrade 
performance,  nor  have  any  negative  side  effects.  Also,  that  the  software  change  required  to  the 
TIS  baseline  to  readout  TIS  register  29  functions  correctly. 


4,4.2  Testing  Description. 

The  Regression  Test  and  Mode  S  RQT  were  conducted  using  procedures  for  the  TIS  release. 

The  procedures  included  general  Mode  S  and  special  TIS  tests. 

The  following  scenarios  were  run  to  verify  that  TIS  had  been  successfully  added  to  the  SAR214F 
baseline:  TISCRCL8,  TISCRDS4,  TISHOLL4,  TISOTLL8,  TIS4424,  TIS441 1SS,  TIS200,  and 
UNBRAMP. 
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4.4.3  Data  Collection  and  Analysis  Method. 

Data  files  were  collected  at  the  Modes  S  (MREG29.922  for  regression)  and  (MCRCL8.922, 
MCRDS4.922,  MHOLL4.922,  MOTLL8.922,  M4424.922,  M441  IS,  MTIS200,  and 
MUNBRAMP.922).  The  data  types  collected  on  the  Mode  S  are  listed  in  section  4.2.2. 

Miscellaneous  Print  RBAT  program  and  the  TIS  Tracker/Alert  analysis  tool  were  used  to  obtain 
a  sequence  listing  and  the  detailed  register  content  for  the  regression  test  data. 

Also,  the  TIS  Analysis  tool  was  used  on  the  test  data  so  that  the  results  could  be  looked  at 
to  ensure  proper  operation  of  the  scenario. 

Output  files  TCRCL8.922,  TCRDS4.922,  THOLL4.922,  TOTLL8.922,  and  T4424.922  were 
generated  from  TIS  Analysis  and  used  to  verify  that  the  scenarios  ran  correctly.  Output  files 
MP4411S.922,  MP441  IS  1.922,  and  MP441 1S3.922  generated  from  RBAT  Miscellaneous  Print 
and  LST441  IS. 922  generated  from  the  TIS  list  program  were  used  to  verify  the  proper  operation 
of  the  TIS441 1 SS  scenario. 


4.4.4  Results/Discussion. 

Data  analysis  files  MP29REG.922  and  QL29REG.922  were  used  for  the  verification  of  the 
Register  29  contents  for  the  regression  testing. 

It  should  be  noted  that  the  output  of  scenario  TISOTLL8  had  a  bearing  reliability  of  81.6  percent 
and  scenario  TIS4424  had  a  bearing  reliability  of  79.0  percent.  The  TISOTLL8  low  bearing 
reliability  can  be  traced  to  numerous  self-alerts  and  the  TIS4424  low  bearing  reliability  can  be 
traced  to  self-alerts  and  a  garbled  ID. 


4.4.5  Conclusions. 


The  TIS  software  worked  correctly  and  the  register  29  data  was  read  out. 

The  low  bearing  reliability  discrepancies  can  be  attributed  to  the  Terra  fix  problem  as  previously 
described  in  this  report. 
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4.5  CPU  UTILIZATION. 


4.5.1  Test  Objective. 

The  objective  of  this  test  was  to  determine  what  value  the  “TIS  Maximum  Aircraft  Supported” 
SAP  should  be  set  to  for  field  deployment.  There  had  not  been  a  specific  value  recommended 
for  this  SAP  at  the  start  of  TIS  testing.  A  value  that  limited  the  maximum  CPU  utilization  for  all 
processors  to  80  percent  or  less,  was  to  be  determined. 


4.5.2  Testing  Description. 

A  special  scenario  was  developed  with  the  TIS  client  count  starting  at  50  and  ramping  up  to  236 
(TUC200).  The  scenario  was  then  run  twice  on  Channel  A  and  twice  on  Channel  B.  At  each 
client  level  increment,  the  CPU  utilization  percentage  of  each  on  the  Mode  S  processors  was 
recorded.  The  scenario  was  allowed  to  continue  until  the  sensor  processors  reached  100  percent 
utilization  and  the  channel  under  test  went  to  “red”  status. 

The  CPU  Utilization  test  was  conducted  using  SAR214.G  TIS  DEBUG  Mode  S  image  on 
August  6  and  7, 1997.  The  tests  were  performed  at  the  Technical  Center  in  Atlantic  City,  NJ. 
The  Mode  S  sensor  and  the  ARIES  simulator  are  located  in  building  269  at  the  Technical  Center. 

ACT-310  staff  along  with  contractor  personnel  performed  the  Special  testing  tasks  such  as 
operating  the  Mode  S  sensor,  technical  support,  collecting  and  analyzing  data. 


4.5.3  Data  Collection. 

Data  collection  was  completed  during  the  test  conduct  by  entering  the  CPU  utilization 
percentage  values  in  the  procedure  tables. 


4.5.4  Results. 

The  following  tables  contain  the  results  from  the  TIS  client  loading  test  runs,  which  were 
conducted  to  determine  a  recommended  value  for  the  “TIS  Maximum  Supported”  SAP  setting. 
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Table  4.35.4-1  below  shows  the  results  from  first  test  run  on  August  6, 1997.  CPU  utilization 
values  were  collected  from  Mode  S  Channel  A  until  the  Mode  S  Channel  A  status  went  “red” 
causing  a  switch  to  Channel  B.  This  occurred  when  the  client  count  had  advanced  to  21 8. 

TABLE  4.35.4-  1 .  CHANNEL  A  CPU  UTILIZATION  FIRST  RUN 
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ur 
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Max  value  =  maximum  percentage  of  CPU  utilization  indicated  for  the  Target  Load  sample 
period 

Cur  value  =  percentage  of  CPU  utilization  indicated  at  the  sample  time  for  the  Target  Load 


Table  4.35.4-2  below  shows  the  results  from  second  test  run  on  August  6,  1997.  CPU  utilization 
values  were  collected  from  Mode  S  Channel  A  until  CPU  1  reached  100  percent.  The  client 
count  in  the  scenario  had  advanced  to  218  and  the  Mode  S  Channel  A  status  went  “red”  causing 
a  switch  to  Channel  B.  Note:  The  Mode  S  status  had  gone  “yellow”  during  the  200  client  level. 


TABLE  4.35.4-  2.  CHANNEL  A  CPU  UTILIZATION  SECOND  RUN 
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Max  value  =  maximum  percentage  of  CPU  utilization  indicated  for  the  Target  Load  sample 
period 

Cur  value  =  percentage  of  CPU  utilization  indicated  at  the  sample  time  for  the  Target  Load 
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Table  4.35.4-3  below  shows  the  results  from  first  test  run  on  August  7,  1997.  CPU  utilization 
values  were  collected  from  Mode  S  Channel  B  until  CPU  1  reached  100  percent.  The  client 
count  in  the  scenario  had  advanced  to  218  and  the  Mode  S  Channel  B  status  went  “red”  causing  a 
switch  to  Channel  A.  Note:  The  Mode  S  status  had  gone  “yellow”  during  the  200  client  level 
and  524  traps  where  listed  in  error  log. 


TABLE  4.35.4-  3.  CHANNEL  B  CPU  UTILIZATION  FIRST  RUN 
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Max  value  =  maximum  percentage  of  CPU  utilization  indicated  for  the  Target  Load  sample 
period 

Cur  value  =  percentage  of  CPU  utilization  indicated  at  the  sample  time  for  the  Target  Load 
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Table  4.35.4-4  below  shows  the  results  from  second  test  run  on  August  7, 1997.  CPU  utilization 
values  were  collected  from  Mode  S  Channel  B  until  CPU  1  reached  1 00  percent.  The  client 
count  in  the  scenario  had  advanced  to  236  and  the  Mode  S  Channel  B  status  went  “red”  causing  a 
switch  to  Channel  A. 


TABLE  4.35.4-  4.  CHANNEL  B  CPU  UTILIZATION  SECOND  RUN 
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Max  value  =  maximum  percentage  of  CPU  utilization  indicated  for  the  Target  Load  sample 
period 

Cur  value  =  percentage  of  CPU  utilization  indicated  at  the  sample  time  for  the  Target  Load 


4,5.5  Conclusions. 

The  shaded  area  of  the  previous  four  tables  show  the  TIS  client  target  load  at  which  CPU 
utilization  rises  above  80  percent.  To  limit  CPU  utilization  for  all  processors  to  80  percent,  a 
TIS  client  load  of  100  must  not  be  exceeded. 

The  “TIS  Maximum  Aircraft  Supported”  SAP  should  be  set  to  100  or  less  for  field  deployment. 
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4.6  DATA  LINK  BAND  WITH  DEMONSTRATION. 


4.6.1  Test  Obiective/Criteria. 

A  very  simple  and  limited  test  was  conducted  during  the  live  flight  tests  to  demonstrate  that  TIS 
does  not  significantly  impact  the  data  link  channel  capacity.  Since  GWS  data  density  can  be 
high,  successful  reception  of  GWS  data  (while  continuing  to  supply  TIS)  would  show  that  there 
is  indeed  ample  excess  capacity  in  the  data  link  channel. 


4.6.2  Test  Description. 

Lincoln  Labs  provided  all  the  additional  hardware,  software  and  GWS  data  feed  to  support  this 
demonstration.  After  the  FAA  test  flight  events  were  completed,  while  running  the  Mode  S 
sensor  with  TIS  active,  one  of  the  aircraft  requested  GWS. 


4.6.3  Data  Collection  and  Analysis  Method. 

Not  Applicable.  No  data  was  collected,  only  observed  on  the  GWS  display. 


4.6.4  Results/Discussion. 

During  the  live  flight  tests  the  ADLP  on  the  FAA  aircraft  was  unable  to  connect  to  the  GWS 
service.  Therefore,  no  GWS  data  was  received.  However,  GWS  service  was  received  (to  a 
ground-based  ADLP  and  TIS  transponder)  during  system  checkout  and  dry-runs. 


4.6.5  Conclusions. 

No  conclusion  could  be  reached  since  the  formal  demonstration  failed. 

However,  in  response  to  a  request  from  the  FAA  Program  Office,  MITLL  supplied  two  GA 
aircraft  and  air  crew  who  flew  modified  versions  of  a  subset  of  the  TIS  DT&E/OT&E  Test  plan 
flight  plans.  These  flights  were  conducted  simultaneous  to,  and  totally  independent  of  the  FAA 
flight  events.  GWS  service  was  received  by  one  of  the  MITLL  aircraft.  See  "Lincoln 
Laboratory  Flight  Test  Results  for  Traffic  Information  Service  (TIS)  Operational  Test  And 
Evaluation"  Report  Number  "42PM-Data-Link-0012"  dated  September  10,  1997,  for  details. 
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5.  CONCLUSIONS. 


Overall,  the  Traffic  Information  Service  (TIS)  data  link  services  worked  as  expected  and  the 
ability  of  Mode  Select  (Mode  S)  to  transfer  data  link  communication  messages  performed 
properly.  The  TIS  tracking  algorithms  performed  flawlessly  and  according  to  specifications, 
with  one  minor  exception.  From  the  results,  it  is  estimated  that  the  overwhelming  majority  of 
TIS  advisories  were  sent  at  the  appropriate  times.  Some  data  in  the  advisories  is  inaccurate  at 
times,  but  that  is  largely  due  to  inaccuracies  in  the  Mode  S  surveillance  data. 

Only  three  minor  problems  were  found.  All  three  were  previously  found  during  the  TIS 
Operational  Test  and  Evaluation  (OT&E)  for  the  Dulles  Demonstration  in  1995.  The  following 
paragraphs  contain  a  summary  of  the  problems. 


5.1  SELF- ALERTS. 

The  self-alert  is  a  relatively  low  frequency,  nuisance  problem.  It  should  be  eliminated  (or 
drastically  reduced)  when  the  Terra  modification  is  removed  from  the  Mode  S  software. 


5.2  INVALID  ALTITUDES. 

The  invalid  TIS  altitude  problem  was  another  low  frequency  issue.  It  is  not  a  TIS  problem  per 
se,  but  a  Mode  S  surveillance  problem  that  has  minor  impact  on  TIS  accuracy.  It  should  be 
corrected  when  there  is  a  solution  to  the  Mode  S  erroneous  altitudes.  This  problem  was 
previously  identified,  but  no  solution  was  available  during  the  TIS  testing. 


5.3  TIS  TRACKING  ANOMALY. 

The  Intruder  "crossover  problem"  is  displayed  in  both  scenario  and  live  flight  data.  It  was 
identified  during  the  Dulles  demo  testing  of  TIS  and  still  is  an  issue  that  poses  the  greatest 
liability.  The  crossover  issue  could  cause  a  pilot,  when  viewing  TIS,  to  potentially  turn  towards 
the  intruder  aircraft  based  on  TIS  information.  Although  this  type  of  maneuvering  should  not 
occur  very  often  during  normal  flights,  it  can  and  does  happen.  The  TIS  Program  as  a  whole 
must  ensure  that  this  problem  is  corrected  or  documented  in  all  pilot/user  related  documentation. 
The  ACT-3 10  test  group  again  emphasizes  the  problem  and  that  it  must  not  be  overlooked. 

In  conclusion,  the  TIS  software  functions  correctly  and  as  good  or  better  than  the  TIS  Dulles 
Demonstration  version  for  all  measured  parameters.  The  addition  of  the  TIS  data  link  services 
appear  to  have  no  adverse  effect  to  the  Mode  S  sensor  operations.  The  Mode  S  data  link 
capabilities  function  properly  providing  alerts  and  TIS  service  status  messages  in  a  timely 
manner. 
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6.  RECOMMENDATIONS. 


After  completion  of  the  formal  Developmental  Test  and  Evaluation/Operational  Test  and 
Evaluation  (DT&E/OT&E)  testing  and  detailed  analysis  and  evaluation  of  Traffic  Information 
Service  (TIS),  ACT-310  recommends  that  TIS  be  conditionally  approved  for  national 
deployment  contingent  upon  the  following: 

a.  The  Aeronautical  Information  Manual  (AIM)  and  all  other  applicable  user  documentation 
must  be  revised  to  thoroughly  document  the  self-alert  problem. 

b.  The  TIS  tracker  anomaly  ("crossover  problem")  must  be  corrected  in  the  TIS  software  or 
the  AIM  (and  applicable  user  docs)  must  be  revised  to  thoroughly  document  this 
limitation. 

c.  This  version  of  TIS  is  only  fielded  in  a  terminal  sensor  configuration. 

The  ACT-310  test  group  also  recommends  that  when  fielded  the  "TIS  Maximum  Aircraft 
Supported"  SAP  be  set  to  the  value  of  100  (or  less)  based  on  keeping  the  maximum  CPU 
utilization  for  all  processors  under  80  percent,  given  the  CPU  utilization  test  results. 

The  following  table  (6-1)  contains  a  summary  of  issues  and  recommendations  suggested  for 
incorporation  prior  to  the  national  deployment  of  the  TIS: 
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TABLE  6-  1. 


TIS  ISSUES  MATRIX 


Seq 

# 

Criticality 

Description  of  Issues 

Proposed  Solution  /  Recommendation 

1 

Medium 

Self-Alerts  occur  due  to 
garbling  of  ATCRBS  IDs, 
altitude  amounts,  and  range 
readings.  The  Terra  software 
algorithm  identifies  these 
reports  as  another  target  in 
close  proximity,  there  by 
creating  the  Self-Alert. 

Removal  of  the  Terra  software  should 
eliminate  these  alerts,  because  the  Mode  S 

ID  would  be  used  for  tracking. 

Until  this  occurs  the  AIM  and  all  other 
applicable  user  ('pilot')  documentation  must 
be  revised  to  document  this  phenomenon. 

NOTE:  The  AIM  is  currently  under  revision 
to  include  this  issue. 

2 

Medium 

Invalid  altitudes  in  excess  of 
50,000  feet  were  assigned  to 
ATCRBS  reports.  These 
invalid  altitudes  affect  the 
performance  of  the  TIS  tracker 
since  TIS  relies  on  the  Mode  S 
ATCRBS  reports. 

Mode  S  software  should  be  fixed  to  correct 
this  problem  and  TIS  reliability  would  then 
be  improved. 

3 

Medium 

Intruder  position  displayed 
incorrectly,  “crossover 
problem.”  For  one  particular 
maneuver,  the  intruder  is 
displayed  on  the  wrong  side  of 
the  client. 

Modify  the  tracker  prediction  algorithm  to 
prevent  this  problem. 

Until  this  occurs  the  AIM  and  all  other 
applicable  user  (pilot!  documentation  must 
be  revised  to  document  this  phenomenon. 

NOTE:  The  AIM  is  currently  under  revision 
to  include  this  issue. 

4 

Low 

CPU  Utilization 

Based  on  a  maximum  allowable  CPU 
!  utilization  of  80  percent,  a  setting  of  100  for 
the  “TIS  Maximum  Aircraft  Supported”  SAP 
is  recommended. 

5 

Low 

TIS  included  in  the  EnRoute 
software  build. 

The  ACT-3 10  test  group  recommends  that 

TIS  be  extended  to  the  Mode  S  EnRoute 
environment.  This  change  would  provide 
additional  service  to  general  aviation 
community. 

CRITICALITY :  Low  -  Minimum  risk  or  impact  that  can  be  fixed  in  a  routine  manner 

Medium  -  Significant  risk  but  can  be  worked  around  on  a  temporary  basis 
High  -  Mission  critical  risk,  must  be  fixed  prior  to  deployment 
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7.  ACRONYMS  AND  ABBREVATIONS. 


ADLP 

Airborne  Data  Link  Processor 

AIM 

Aeronautical  Information  Manual 

AIN 

Application  Identification  Number 

ARIES 

Aircraft  Reply  and  Interference  Environmental  Simulator 

ASR-9 

Airport  Surveillance  Radar  Model  9 

AT 

Air  Traffic 

ATC 

Air  Traffic  Control 

ATCBI-5 

Air  Traffic  Control  Beacon  Interrogator  Model  5 

ATCRBS 

Air  Traffic  Control  Radar  Beacon  System 

CID 

Communications  Interface  Driver 

COI 

Critical  Operational  Issues 

CPME 

Calibration  Precision  Monitoring  Equipment 

CPU 

Central  Processor  Unit 

DI 

Dimensions  International,  Inc. 

DT&E 

Developmental  Test  and  Evaluation 

DR 

Data  Reduction  Program 

GICB 

Ground-initiated  Comm  B  transponder  register 

GWS 

Graphical  Weather  Service 

IBI 

Interim  Beacon  Interrogator 

ID 

Identification 

LMT 

Local  Maintenance  Terminal 

ISLS 

Improved  side  lobe  suppression. 

MITLL 

Massachusetts  Institute  of  Technology  Lincoln  Laboratory 

Mode  S 

Mode  Select 
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MSL 

Mean  Sea  Level 

MSP 

Mode  S-Specific  Protocol 

NAS 

National  Airspace  System 

OT&E 

Operational  Test  and  Evaluation 

PC 

Personal  Computer 

Pd 

Probability  of  Detection 

Pfa 

Probability  of  False  Alarm 

RBAT 

Radar  Beacon  Analysis  Tool 

RF 

Radio  Frequency 

RIT 

Radar  Intelligence  Tool 

RT 

Remote  Terminal 

RTADS 

Real-Time  Aircraft  Display  System 

RU 

Mode  S  sensor  Range  Unit 

SAP 

Site  Adaptation  Parameter 

SCIP 

Surveillance  and  Communication  Interface  Processor 

SCM 

System  Configuration  Managed 

SLS 

Side  Lobe  Suppression. 

SPR 

System  Problem  Report 

STC 

Sensitivity  Time  Constant 

T&E 

Test  and  Evaluation 

TCAS 

Traffic  Alert  and  Collision  Avoidance  System 

TIS 

Traffic  Information  Service 

TSCR 

TIS  Connection  Request 

TSDR 

TIS  Disconnection  Request 

TU 

Mode  S  sensor  Time  Unit 

TVRTM 

Test  Verification  Requirements  Traceability  Matrix 
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APPENDIX  A 

SCENARIO  DESCRIPTIONS 


SCENARIO  DESCRIPTIONS 


Scenario  Identifier 

Parameters  of  Scenario  || 

TISCRCL4 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  a  Crossing  pattern,  while  Climbing,  with  the  client  located  45  miles 
from  sensor  flying  North  at  start  of  the  scenario.  The  intruder  flies  east 
crossing  the  client’s  flight  path.  The  client  flies  at  a  constant  speed  of  ! 
120  knots  and  the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISCRCL8 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  a  Crossing  pattern,  while  Climbing,  with  the  client  located  8  miles 
from  sensor  flying  North  at  start  of  the  scenario.  The  intruder  flies  east 
crossing  the  client’s  flight  path.  The  client  flies  at  a  constant  speed  of 

120  knots  and  the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISCRDS4 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  a  Crossing  pattern,  while  Descending,  with  the  client  starting  45 
miles  from  sensor  flying  North  at  start  of  scenario.  The  intruder  flies 
east  crossing  the  client’s  flight  path.  The  client  flies  at  a  constant  speed 
of  120  knots  and  the  intruder  flies  at  a  constant  speed  of  1 50  knots. 

TISCRDS8 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  a  Crossing  pattern,  while  Descending,  with  the  client  starting  8  miles 
from  sensor  flying  North  at  start  of  scenario.  The  intruder  flies  east 
crossing  the  client’s  flight  path.  The  client  flies  at  a  constant  speed  of 

120  knots  and  the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISCRLL4 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  a  Crossing  pattern,  in  Level  flight,  with  the  client  starting  45  miles 
from  sensor  flying  North  at  start  of  scenario.  The  intruder  flies  east 
crossing  the  client’s  flight  path.  The  client  flies  at  a  constant  speed  of 

120  knots  and  the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISCRLL8 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  a  Crossing  pattern,  in  Level  flight,  with  the  client  starting  8  miles 
from  sensor  flying  North  at  start  of  scenario.  The  intruder  flies  east 
crossing  the  client’s  flight  path.  The  client  flies  at  a  constant  speed  of 

120  knots  and  the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISHCSP4 

This  scenario  consists  of  one  TIS  client  and  two  intruders.  The  aircraft 
primary  (FAA001  and  FAA002)  fly  Head-On,  while  Climbing,  with  the 
client  (FAA001)  starting  45  miles  from  sensor  flying  North.  A  second 
intruder,  ATCRBS  only,  was  added  and  this  intruder  crosses  the  client’s 
flight  path  after  the  primary  intruder  has  passed  the  client.  The  beacon 
responses  will  be  inhibited  from  all  IDs  for  a  few  scans  to  cause  track 
coasts  and  track  drops.  The  client  flies  at  a  constant  speed  of  120  knots 
and  the  intruders  fly  at  a  constant  speed  of  150  knots. 
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Scenario  Identifier 

Parameters  of  Scenario 

TISHCSP8 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  Head-On,  while  Climbing,  with  the  client  starting  8  miles  from 
sensor  at  start  of  scenario  and  the  rate  of  altitude  change  will  be  at  400 
feet  per  minute.  The  client  flies  at  a  constant  speed  of  120  knots  and  the 
intruder  flies  at  a  constant  speed  of  150  knots. 

TISHCSPX 

This  scenario  consists  of  one  TIS  client  and  two  intruders.  The  primary 
(FAA001  and  FAA002)  aircraft  fly  Head-On,  while  Climbing,  with  the 
client  (FAA001)  starting  45  miles  from  sensor  at  start  of  scenario.  A 
second  intruder,  ATCRBS  only,  was  added  and  this  intruder  crosses  the 
client’s  flight  path  after  the  primary  intruder  has  passed  the  client.  The 
altitude  responses  will  be  inhibited  from  all  IDs  for  up  to  10  scans  to 
cause  track  coasts  and  track  drops.  The  client  flies  at  a  constant  speed  of 
120  knots  and  the  intruders  fly  at  a  constant  speed  of  150  knots. 

TISHDSP8 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  Head-On,  while  Descending,  with  the  client  starting  8  miles  from 
sensor  at  start  of  scenario  and  the  rate  of  altitude  change  will  be  at  400 
feet  per  minute.  The  client  flies  at  a  constant  speed  of  120  knots  and  the 
intruder  flies  at  a  constant  speed  of  150  knots. 

TISHLSP4 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  Head-On,  in  Level  flight,  with  the  client  starting  45  miles  from 
sensor.  The  intruder  will  fly  South  at  1 50  knots  and  increase  speed  to 

280  knots  during  scenario.  The  client  flies  at  a  constant  120  knots. 

TISHLSP8 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  Head-On,  in  Level  flight,  with  the  client  starting  8  miles  from 
sensor.  The  client  will  fly  North  at  120  knots  and  increase  speed  to  280 
knots  during  scenario.  The  intruder  flies  at  a  constant  150  knots. 

TISHOCL4 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  Head-On,  while  Climbing,  with  the  client  starting  45  miles  from 
sensor  flying  North  at  start  of  scenario.  The  intruder  flies  South  until  it 
has  passed  the  client  by  10  miles.  The  client  flies  at  a  constant  speed  of 
120  knots  and  the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISHOCL8 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  Head-On,  while  Climbing,  with  the  client  starting  8  miles  from 
sensor  flying  North  at  start  of  scenario.  The  intruder  flies  South  until  it 
has  passed  the  client  by  10  miles.  The  client  flies  at  a  constant  speed  of 
120  knots  and  the  intruder  flies  at  a  constant  speed  of  150  knots. 

NONHOCL8 

Same  event  as  TISHOCL8,  but  there  are  no  duplicate  ATCRBS  targets 
for  Terra  mode.  This  is  a  Non-Terra  version  of  scenario  TISHOCL8. 

TISHODS5 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  Head-On,  while  Descending,  with  the  client  starting  45  miles  from 
sensor  flying  North  at  start  of  scenario.  The  intruder  flies  South  until  it 
has  passed  the  client  by  10  miles.  The  client  flies  at  a  constant  speed  of 
120  knots  and  the  intruder  flies  at  a  constant  speed  of  150  knots. 

Scenario  Identifier 

Parameters  of  Scenario 

TISHODS8 

This  scenario  consists  of  one  TIS  client  and  three  intruders.  The 
primary  aircraft  (FAA001  and  FAA002)  fly  Head-On,  while 

Descending,  with  the  client  (FAA001)  starting  8  miles  from  sensor 
flying  North  at  start  of  scenario.  The  client  (FAA001)  flies  at  a  constant 
speed  of  120  knots  and  the  intruder  (FAA002)  flies  at  a  constant  speed 
of  150  knots.  The  intruder  (FAA002)  flies  South  until  it  has  passed  the 
client  by  10  miles.  Two  additional  intruders  flying  at  100  knots  were 
added  later  in  the  scenario  to  generate  alerts  with  the  client  as  the 
intruders  pass.  These  intruders  are  only  active  for  1  minute  and  are  then 
dropped. 

TISHOLL4 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  Head-On,  in  Level  flight,  with  the  client  starting  45  miles  from 
sensor  flying  North  at  start  of  scenario.  The  intruder  flies  South  until  it 
has  passed  the  client  by  10  miles.  The  client  flies  at  a  constant  speed  of 
120  knots  and  the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISHOLL8 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  Head-On,  in  Level  flight,  with  the  client  starting  8  miles  from  sensor 
flying  North  at  start  of  scenario.  The  intruder  flies  South  until  it  has 
passed  the  client  by  10  miles.  The  client  flies  at  a  constant  speed  of  120 
knots  and  the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISOTCL4 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  an  Overtaking  route,  while  Climbing,  with  the  client  starting  45 
miles  from  sensor  flying  North  at  start  of  scenario.  The  intruder  will 
overtake  and  pass  the  client.  The  client  flies  at  a  constant  speed  of  120 
knots  and  the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISOTCL8 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  an  Overtaking  route,  while  Climbing,  with  the  client  starting  8  miles 
from  sensor  flying  North  at  start  of  scenario.  The  intruder  will  overtake 
and  pass  the  client.  The  client  flies  at  a  constant  speed  of  120  knots  and 
the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISOTDS4 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  an  Overtaking,  while  Descending,  with  the  client  starting  45  miles 
from  sensor  flying  North  at  start  of  scenario.  The  intruder  will  overtake 
and  pass  the  client.  The  client  flies  at  a  constant  speed  of  120  knots  and 
the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISOTDS8 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  an  Overtaking  route,  while  Descending,  with  the  client  starting  8 
miles  from  sensor  flying  North  at  start  of  scenario.  The  intruder  will 
overtake  and  pass  the  client.  The  client  flies  at  a  constant  speed  of  120 
knots  and  the  intruder  flies  at  a  constant  speed  of  1 50  knots. 

Scenario  Identifier 

Parameters  of  Scenario 

TISOTLL4 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  an  Overtaking  route,  in  Level  flight,  with  the  client  starting  45  miles 
from  sensor  flying  North  at  start  of  scenario.  The  intruder  will  overtake 
and  pass  the  client.  The  client  flies  at  a  constant  speed  of  120  knots  and 
the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISOTLL8 

This  scenario  consists  of  one  TIS  client  and  one  intruder.  The  aircraft 
fly  an  Overtaking  route,  in  Level  flight,  with  the  client  starting  8  miles 
from  sensor  flying  North  at  start  of  scenario.  The  intruder  will  overtake 
and  pass  the  client.  The  client  flies  at  a  constant  speed  of  120  knots  and 
the  intruder  flies  at  a  constant  speed  of  150  knots. 

TISXOVRB 

This  scenario  consists  of  one  TIS  client  flying  North  on  a  Level  flight,  8 
miles  from  sensor  at  start  of  scenario.  A  single  intruder  aircraft  will 
approach  from  4  miles  on  an  angle  to  within  1/4  mile,  then  turn  sharply 
and  fly  parallel  to  the  client.  The  client  flies  at  a  constant  speed  of  135 
knots  and  the  intruder  flies  at  a  speed  of  141  knots  until  the  turn,  then 
increases  speed  to  218  knots. 

TISXOVRS 

Same  event  as  TISOVRB,  but  there  are  no  duplicate  ATCRBS  targets 
for  Terra  mode.  This  is  a  Non-Terra  version  of  scenario  TISXOVRB. 

TIS200 

This  scenario  consists  of  150  ATCRBS  targets  and  50  TIS  client 
aircraft.  The  50  TIS  clients  issue  requests  for  service  during  the 
scenario.  The  client  aircraft  fly  at  speeds  as  low  as  30  knots  up  to  160 
knots.  The  ATCRBS  intruder  aircraft  fly  at  speeds  from  35  knots  up  to 
160  knots.  All  the  aircraft  are  located  in  a  dense  pattern  of 
approximately  125°. 

NON200 

Same  event  as  TIS200,  but  there  are  no  duplicate  ATCRBS  targets  for 
Terra  mode.  This  is  a  Non-Terra  version  of  scenario  TIS200. 

TIS4411S 

This  scenario  consists  of  six  different  targets  requesting  TIS  service. 

The  first  target  starts  within  coverage  and  flies  outbound  beyond  75  nmi 
range.  The  second  target  starts  outside  the  75  nmi  range  and  flies 
inbound  into  coverage.  The  third  target  will  fly  through  the  zenith  cone. 
The  forth  target  starts  in  the  center  of  the  zenith  cone  and  flies  outbound 
leaving  the  zenith  cone.  The  fifth  target  does  not  request  TIS  service 
until  the  scenario  has  been  running  for  awhile.  The  sixth  target  starts  on 
the  y-axis  55  nmi  to  the  east  and  flies  north  descending  to  —100  feet 
altitude  and  then  returning  to  4000  feet.  FAA001  and  FA002  fly  at  420 
knots;  FAA003  flies  at  480  knots;  FAA004  and  FAA005  fly  at  240 
knots;  and  FAA006  flies  at  120  knots. 

TIS4421 

This  scenario  consists  of  one  TIS  client  flying  outbound  on  a  radial 
situated  between  two  intruder  aircraft  flying  one  degree  to  the  left  and 
right.  The  client  and  intruders  fly  at  a  constant  60  knots. 
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Scenario  Identifier 

Parameters  of  Scenario 

TIS4422 

This  scenario  consists  of  3  groups  of  5  targets,  each  containing  one  TIS 
client  with  four  intruders.  The  clients  all  fly  outbound,  as  well  as  the 
intruders.  The  groups  are  different  as  far  as  intruder  altitude  and 
heading  in  relation  to  the  client.  Each  group  will  cause  a  different 
sequence  of  proximate  and  traffic  advisories.  The  client  aircraft  fly  at  a 
constant  speed  of  60  knots  and  the  intruders  fly  at  constant  speeds  of  62 
and  63  knots. 

TIS4423 

This  scenario  consists  of  one  TIS  client  and  eight  intruders.  Four  of  the 
intruders  will  generate  proximate  advisories  and  four  of  the  intruders 
will  generate  traffic  advisories.  The  client  aircraft  flies  at  a  constant 
speed  of  60  knots  and  the  intruders  fly  at  constant  speeds  of  61, 62,  and 

63  knots. 

NON4423 

Same  event  as  TIS4423,  but  there  are  no  duplicate  ATCRBS  targets  for 
Terra  mode.  This  is  a  Non-Terra  version  of  scenario  TIS4423. 

TIS4424 

This  scenario  consists  of  1  TIS  client  and  12  intruders.  The  12  intruders 
will  fly  so  as  to  cause  12  advisories  to  be  generated  at  1  time.  The  client 
aircraft  flies  at  a  constant  speed  of  60  knots  and  the  intruders  fly  at 
constant  speeds  of  60,  62,  and  120  knots. 

NON4424 

Same  event  as  TIS4424,  but  there  are  no  duplicate  ATCRBS  targets  for 
Terra  mode.  This  is  a  Non-Terra  version  of  scenario  TIS4424. 

UNBRAMP 

This  scenario  starts  with  50  TIS  client  aircraft  and  then  increases  the 
number  of  TIS  client’s  by  10  every  2  minutes  until  it  reaches  200  TIS 
clients.  The  targets  are  spread  out  over  the  entire  coverage  area  and  fly 
at  range  of  speeds  from  50  knots  to  as  high  as  630  knots. 
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Client  =  6600  feet,  170  KIAS,  N  39 

Intruder  =  6200  feet,  220  KIAS,  N  49 

A.  During  this  event,  the  Intruder  (I)  aircraft  over  took  the  Client  (C)  aircraft  flying  at  400  feet 
below  and  parallel  to  the  Client,  until  the  Intruder  was  at  least  3  nmi  ahead  of  the  Client.  The 
Intruder  then  made  a  1 80°  turn  to  the  left  closing  to  a  range  of  approximately  3  nmi  and  flew  in 
the  opposite  direction  of  the  Client  on  a  parallel  path  until  it  had  passed  the  Client. 

Event  B 
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Client  =  6600  feet,  180  KGS,  N39 

Intruder  =  6300  feet,  180  KGS,  N  49 

B.  During  this  event,  the  Intruder  (I)  aircraft  passed  perpendicular  and  behind  the  Client  (C) 
aircraft  at  approximately  1  nmi  and  300  feet  below  the  Client. 
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Event  C 
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Client  =  6900  feet,  180  KGS,  N  39 

Intruder  =  6300  feet,  180  KGS,  N  49 

C.  During  this  event,  the  Intruder  (I)  crossed  ahead  of  the  Client  (C)  at  a  range  of  approximately 
2  nmi  and  600  feet  below  the  Client. 


Event  D 


Client  =  6600  feet,  180  KIAS,  N  39 

Intruder  =  5600  feet,  180  KIAS,  N  49 

D.  During  this  event,  the  Intruder  (I)  flew  on  the  same  course  as  the  Client  (C),  starting  at  1000 
feet  below  the  Client.  The  Intruder  then  ascended  at  200  feet  per  minute  to  within  500  feet  of  the 
Client.  The  Intruder  then  continued  on  the  same  course  as  Client  descending  at  a  rate  of  700  feet 
per  minute  to  an  altitude  on  1000  feet  below  Client. 
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Event  E 


Client  =  6900  feet,  180  KGS,  N  39 

Intruder  =  6300  feet,  180  KGS,  N  49 

E.  During  this  event,  the  Client  (C)  flew  on  a  25°  arc  at  a  range  of  25  nmi  from  the  sensor 
(ACY).  The  Intruder  (I)  then  started  30  nmi  from  the  sensor  (ACY)  and  flew  perpendicular 
through  the  arc  at  an  altitude  of  600  feet  below  the  Client  at  the  crossing  point. 


Event  F 


Elevation 


Client  =  6600  feet,  170  KGS,  N39 

Intruder  =  6200  feet,  170  KGS,  N  49 

F.  During  this  event,  the  Client  (C)  and  the  Intruder  (I)  flew  head-on  (opposite  directions)  at  an 
altitude  difference  of  500  feet  on  the  same  radial  starting  at  5  nmi  apart  and  closed  passing  over 
each  other.  The  Intruder  was  at  an  altitude  400  feet  below  the  Client  when  they  passed  under. 
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Event  G 


Client  =  6300  feet,  150  KIAS,  N  39 

Intruder  =  6900  feet,  220  KIAS,  N  49 

G.  This  event  was  planned  for  the  Client  (C)  to  fly  clockwise  on  an  arc  at  a  range  of  35  nmi 
from  the  sensor  (ACY).  The  Intruder  (I)  started  5  nmi  behind  the  Client  flying  on  the  same  arc, 
but  before  overtaking  the  Client  the  aircraft  had  to  reverse  direction  due  to  airspace  limitations. 
The  Client  became  the  Intruder  and  then  continued  until  it  overtook  the  Client  (old  Intruder).  The 
Intruder  flew  at  an  altitude  600  feet  above  the  Client  until  it  was  5  nmi  ahead  of  the  Client. 


Event  H 


Plan  View 
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Client  =  6600  feet,  160  KIAS,  N39 

Intruder  =  6300  feet,  160+  KIAS,  N  49 

H.  For  this  event,  the  Client  (C)  flew  in  a  straight  line.  The  Intruder  (I)  flew  an  S  pattern 
crossing  the  Client’s  flight  path  by  approximately  1/2  nmi  before  turning.  The  Intruder  crossed 
over  four  times  as  they  overtook  and  passed  the  Client  at  an  altitude  300  feet  below  the  Client. 
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Event  I 


Plan  View 


Client  =  6600  feet,  150KIAS,  N39 

Intruder  =6300  feet,  220KIAS,  N49 

I.  During  this  event,  the  Intruder  (I)  started  from  a  range  of  2  nmi  behind  and  2  nmi  off  the  right 
wing  of  the  Client  (C).  The  Intruder  then  flew  toward  the  Client  to  a  range  of  approximately  1/2 
nmi  and  then  turned  right  to  a  path  parallel  to  the  Client.  The  Intruder  then  flew  ahead  of  the 
Client  for  one  minute.  The  Intruder  flew  at  300  feet  below  Client. 

NOTE:  This  event  was  conducted  outside  30  nmi  of  the  sensor  and  within  30  nmi  of  the  sensor. 


Event  J 


Elevation 


^  Sensor  ^ 


Client  =  6600  feet  and  6600  feet,  170  KIAS,  N  39 

Intruder  =  3700  feet  and  6200  feet,  170  KIAS,  N  49 

J.  During  this  event,  the  Client  (C)  and  the  Intruder  (I)  aircraft  flew  through  the  zenith  cone  at 
the  ACY  Mode  S  sensor  (Lat  39°  27  min  5.54  sec,  Long  74°  34  min  14.21  min)  to  a  range  of  5 
nmi  past  ACY.  Two  passes  through  the  zenith  cone  were  conducted.  In  the  first  pass,  the 
aircraft  had  an  altitude  difference  of  2900  feet  and  during  the  second  pass  the  altitude  difference 
was  500  feet.  The  altitude  differences  allowed  the  test  group  to  observe  the  affect  of  the  zenith 
cone  angle.  The  Intruder  was  within  1  nmi  of  the  Client  during  both  passes. 
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Event  K 


Client  =  6600  feet,  Aprox.  170  KIAS,  N  39 

Intruder  =  6300  feet,  Aprox.  170  KIAS,  N  49 

K.  During  this  flight  maneuver,  the  aircraft  went  beyond  the  edge  of  sensor  coverage.  When 
this  occurred  the  Client  (C)  and  the  Intruder  (I)  continued  on  the  flight  paths  that  took  them 
approximately  75  nmi  from  sensor  (ACY).  The  aircraft  then  made  turns  that  returned  them  back 
into  ACY  coverage. 

Event  L 

Plan  View 
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Client  =  6600  feet,  160  KIAS,  N39 

Intruder  =  6200  feet,  220  KIAS,  N  49 

L.  During  this  event,  the  Intruder  (I)  and  Client  (C)  flew  on  the  same  radial  with  the  Intruder 
starting  5  nmi  to  the  rear  of  the  Client.  The  Intruder  closed  to  1/2  nmi  of  the  Client,  then  the 
Intruder  turned  on  a  45°  course  to  the  left  of  the  Client  and  continued  for  2  nmi.  The  Intruder 
flew  at  400  feet  below  the  Client’s  altitude. 
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APPENDIX  C 

PRODUCT  TEST  VERIFICATION  REQUIREMENTS  TRACEABILITY 

MATRIX  (TVRTM) 


TEST  VERIFICATION  REQUIREMENTS  TRACEABILITY  MATRIX 


link  functions. 

An  input  from  the  sensor  data  link  functions  shall  provide  the  source  of  TIS  downlink  OT&E  FT  4.3.1  Live  Fit  #  1 

request  messages  which  enable  or  disable  TIS  service  to  a  particular  aircraft 


Internal  x-y  velocity  XDI,YDI 

Internal  firmness  FIRMI 

External  x-y  position  XPE,YPE 

External  x-y  velocity  XDE,YD1 

External  firmness  FIRME 
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17.0  3.2.2  The  TIS  coverage  map  shall  have  entries  indexed  by  range  and  azimuth.  DT&E 


28.0  3.2.4  Tracks  of  a  desired  speed  range  located  in  a  geographic  position  shall  be  identified  DT&E 

through  the  following  steps: 

1 )  choose  the  appropriate  sort  list  header  array  based  on  speed 
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39.0  3.3.2  The  TIS  Maximum  Aircraft  Supported  SAP  shall  control  the  number  of  aircraft  OT&E  SD  4.2.30 

requesting  TIS  service  that  may  be  granted  service. 


53.0  |  3.4.2  |  For  each  range-azimuth  cell  in  the  US  coverage  map,  a  search  shall  be  performed  DT&E 
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59.0  3.4.3  The  TIS  zenith  cone  table  shall  be  precomputed  during  initialization. _  DT&E 

60.0  3.4.3  The  TIS  zenith  cone  table  shall  be  indexed  by  altitude  and  shall  return  the  slant  range  DT&E 

inside  which  a  goodbye  message  needs  to  be  sent. 


88.0  3.5.2  If  the  message  is  an  ATCRBS  type,  the  tracker  task  shall  update  the  TIS  track  and  sort  OT&E  SD  4.2.24  TIS200 

bin  linkages  for  the  surveillance  track  being  processed. 
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Req.  #  Spec  Requirement  Text  Test  Verification  Test  Report  Test  Scenario 

Para  Phase  Method  Verification  or  Live  Flight 

Paragraph 

96.0  3.5.2. 1  After  a  TIS  track  has  been  projected  horizontally,  any  required  changes  to  the  TIS  DT&E  AT  4.2.3  TISCRCL8 

track  sort  bin  linkages  shall  be  performed,  based  on  the  projected. 
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bin  linkages  shall  then  be  performed. 
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123.0  3.5.3  TIS  horizontal  tracking  shall  be  performed  in  x-y  coordinates.  DT&E 

124.0  3.5.3  Three  updates  shall  be  required  to  fully  initialize  a  track.  DT&E 
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143.0  3. 5.3.3  If  the  horizontal  track  state  is  now  MATURE,  and  if  the  TIS  track  is  a  CPME,  DT&E  Cl  4.1  N/A 

_ performance  monitoring  tracker  checks  shall  be  performed  to  ensure  that  the  tracker 
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thk  =  THK(TRACK.FIRMI) 
D2TH  =  D2TH  *  thk 
IF  (D2  <=  D2TH)  THEN 
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TRACK.  alt_trans_diff  =  trans_difF 

trans  sign  =  sign(trans_difl)  climbing  (+),  descending  (-),  or  level  (0) 
atransjdifT  =  |trans_diff] 
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input  TIS  track  and  the  potential  alert  track  shall  be  calculated. 

215.0  3.6.3. 1  If  "duplicate"  is  FALSE,  and  if  the  absolute  range  difference  is  greater  than  0.1  DT&E  Cl  4.1  N/A 

nautical  mile  (20  RU),  or  if  the  absolute  azimuth  difference  is  greater  than  0.88 
degrees  (40  AU),  then  the  potential  alert  track  shall  not  be  considered  a  potential 
duplicate  and  Terra  checking  for  the  pair  of  tracks  shall  be  complete. 


2 1 6.0  3.6.3. 1  If  "duplicate"  is  FALSE,  and  Terra  checking  should  continue,  an  altitude  test  shall  be  DT&E 

performed. 
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226.0  3. 6.3.2  The  determination  of  the  alert  "threat"  condition  shall  be  based  on  the  calculation  of  DT&E  AT  4.2.13  TISHOLL8 

"time  to  closest  approach",  denoted  as  "tau",  along  with  the  horizontal  and  vertical 

separations  of  the  aircraft  positions.  _ 

227.0  3.6.3.2  The  horizontal  tau  shall  be  calculated  as  follows;  DT&E  AT  4.2.13  TISHOLL8 


r2  =  dx**2  +  dy**2  square  of  separation,  saved  for  sorting  later 

dot  =  dx*dvx  +  dy*dvy  dot  product  of  velocity  vectors 

IF  (dot  -  0)  THEN  th  =  -1  protect  against  "divide  by  zero"  -  force 
divergence 
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Project  traffic  position  ahead  to  next  scan  time 

dthoriz  =  REPORT. time  +  scantime  -  TRAFFIC,  lastupdtime 
divert  =  REPORT. time  +  scantime  -  TRAFFIC .  alt_upd_time 
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284.0  3.6.5. 1.4  The  calculation  of  traffic  range  shall  be  performed  as  follows:  DT&E 


t:  g  js 
o.2  a 

CL  *2  08 

O  » 

««=  8P 

S  S  I 
H  >  ft- 


_  mm  OO  (N  00  ''t  (N  VO 

—  —  —  —  NNn^'nw 

^  M  GO  M  l  u  us 

•  a'aia'Q'a:oi,:!ioioioioiaioioi  A 

v  V  V  V  V  V  VVVP4 
V  V  V  V  V  I^^oorsoovorpcs 


oooooooo 

oooooooo 

«fn’t‘n'Ots*ooo\ 

vvvvvvvv 

•S'S’S’S’S’S’S’S 

ii  n  ii  ii  ii  ii  ii  ii 
vvvvvvvv 

OOOOOOOO 

oooooooo 

'  M  ro  Tf  ID  \£)  00 


C-36 


g88g880!  8 

2  —  <N  <N  rn  ®  O  , 
vVVVVVw*f®Jl 

^’S’S'S'S'S 

n  n  ii  ii  ii  ii  ^  S  w  w 
Jvvvvv^|vv 
ooooo  p  o  o 

OOOOOO  “’oo 

oo»no»no  o 

On  *-  -  fS  fS  £  •» 


o  o  o  o 
o  o  o  © 

<?  t  v 

V  1/  V  V 

•8 -8  a  a- 


o  o  o  o 
o  o  o  o 

m  Tf  ir>  \D 
111* 


8888 

o  »n  o  m  _ 

T  '7^r?8 

$  $  <H>I? 

•S  "S  ■S  •S  ^ 

v  v  v  V  n 

o  o  o  o 
o  o  o  o 
<no^o 

^-M(S  w 


•s  | 
g  s 
a  a 


O  —  Mw^<nv0h  00  0\0^  (NM^invOhMONO^ 


•S  3 

1 1 

s  I 


II  .a  w 

«s  2-tw 

•3  &  a 


*n 

*n 

vri 

vo 

vo 

VO 

r*S 

rn 

ro 

o 

© 

O 

© 

00 

OV 

Os 

CN 

<N 

<N 

C-37 


292.0  3.6.5. 1.4  The  3-bit  Traffic  Heading  field  shall  contain  the  ground  track  angle  of  the  alert  OT&E  SD  4.2.5  TISCRDS8 

aircraft  quantized  to  45-degree  (i.e.  compass-point)  increments. 


293.0  3.6.5. 1.4  The  Traffic  Heading  field  shall  be  calculated  by  the  following:  DT&E 

Theading  =  Integer(AT  C_atan2(TRAFFIC .  XDE, TRAFFIC .  YDE)  /  45 
degrees) 
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APPENDIX  D 

TIS  ANALYSIS  PROGRAM  DESCRIPTION 


TIS  ANALYSIS  PROGRAM  DESCRIPTION 


The  TIS  Analysis  program  is  one  of  the  analysis  programs  that  comprise  the  Radar  Beacon 
Analysis  tool  (RBAT).  TIS  Analysis  provides  a  comparison  of  the  tracks  and  alerts  generated  by 
the  TIS  software  to  those  computed  by  the  analysis  software  using  the  target  data  from  the  Mode 
S.  This  analysis  ensures  that  when  TIS  generates  the  two  types  of  advisories  to  the  client 
aircraft,  Traffic  and  Proximity,  it  is  providing  accurate  information. 

NOTE:  A  Traffic  Advisory  is  for  intruders  within  0.5  nautical  mile  (nmi)  and  800  feet  in  altitude 
of  the  client  and  the  Proximity  Advisory  is  for  intruders  within  5  nmi  and  1200  feet  of  the  client. 

Within  this  test  report  the  analysis  output  indicates  the  comparison  of  the  target  tracks  for 
accuracy  of  the  TIS  tracking  software.  The  client  summary  format  and  uncorrelated  message 
format  have  been  used  to  show  the  results  of  the  TIS  testing,  but  the  TIS  analysis  program  has 
additional  options  which  can  provide  additional  information  about  the  client  and  intruder  aircraft 
if  desired. 

The  client  summary  output  contains  the  following  column  headings  and  a  brief  description  of 
each  is  included  here: 

(1)  Client  -  client  number  in  decimal. 

(2)  Mode  S  ID  -  Mode  S  ID  in  hexadecimal. 

(3)  Traffic  Advisory  Size  -  sample  size  for  the  traffic  advisory  reliability. 

(4)  Traffic  Advisory  Rel  -  traffic  advisory  reliability  which  is  the  percent  of  times  when  a  traffic 
advisory  message  is  determined  by  the  TIS  Analysis  program  that  there  is  a  correlating  TIS 
advisory  message. 

(5)  Traffic  Advisory  Size  -  sample  size  for  the  traffic  advisory  false  alarm  rate. 

(6)  Traffic  Advisory  FAlrm  -  traffic  advisory  false  alarm  rate  which  is  the  percent  of  times  when 
there  is  a  TIS  traffic  advisory  message  and  there  is  no  correlating  advisory  message  determined 
by  the  TIS  Analysis  program. 

(7)  Proximity  Advisory  Size  -  sample  size  for  the  proximity  advisory  reliability. 

(8)  Proximity  Advisory  Rel  -  proximity  advisory  reliability  which  is  the  percent  of  times  when  a 
proximity  advisory  message  is  determined  by  the  TIS  Analysis  program  that  there  is  a  correlating 
TIS  advisory  message. 

(9)  Proximity  Advisory  Size  -  sample  size  for  the  proximity  advisory  false  alarm  rate. 

(10)  Proximity  Advisory  FAlrm  -  proximity  advisory  false  alarm  rate  which  is  the  percent  of 
times  when  there  is  a  TIS  proximity  advisory  message  and  there  is  no  correlating  advisory 
message  determined  by  the  TIS  Analysis  program. 

(11)  Bearing  Reliability  Size  -  sample  size  for  the  bearing  reliability. 

(12)  Bear  -  bearing  reliability  which  is  the  percent  of  times  the  quantized  bearing  from  the  TIS 
advisory  message  is  within  five  (30°)  of  the  quantized  bearing  determined  by  the  TIS  Analysis 
program.  Note  that  the  bearing  is  not  defined  if  the  quantized  range  is  zero  in  the  TIS  advisory 
message  and  that  the  sample  size  for  the  bearing  reliability  may  differ  from  the  reliability  size 
given  in  (11). 

(13)  Reliability  Size  -  sample  size  for  the  range,  altitude,  altitude  rate,  heading,  and  status 
reliabilities. 
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(14)  Range  -  range  reliability  which  is  the  percent  of  times  the  quantized  range  from  the  TIS 
advisory  message  is  within  one  of  the  quantized  range  determined  by  the  TIS  Analysis  program. 

(15)  Alt  -  altitude  reliability  which  is  the  percent  of  times  the  quantized  relative  altitude  from  the 
TIS  advisory  message  is  within  two  of  the  quantized  relative  altitude  determined  by  the  TIS 

Analysis  program.  . 

(16)  ARate  -  altitude  rate  reliability  which  is  the  percent  of  times  the  quantized  altitude  rate  from 

the  TIS  advisory  message  is  the  same  as  the  quantized  altitude  rate  determined  by  the  TIS 
Analysis  program. 

(17)  Head  -  heading  reliability  which  is  the  percent  of  times  the  quantized  heading  from  the  TIS 
advisory  message  is  within  one  of  the  quantized  relative  altitude  determined  by  the  TIS  Analysis 
program. 

(18)  Stat  -  status  reliability,  which  is  the  percent  of  times  the  status  from  the  TIS  advisory 
message  is  the  same  as  the  status,  determined  by  the  TIS  Analysis  program. 


The  uncorrelated  message  and  listing  output  contains  the  following  column  headings  and  a 
brief  description  of  each  is  included  here: 


(1)  Time-Of-Day  -  client  time-of-day  in  HH:MM:SS.FFF. 

(2)  Range  -  client  range  in  nautical  miles. 

(3)  Azmth  -  client  azimuth  in  degrees. 

(4)  Alt  -  client  altitude  in  feet. 

(5)  Head  -  client  heading  as  computed  by  the  TIS  Analysis  program  in  degrees. 

(6)  TisHd  -  client  heading  as  computed  by  TIS  in  degrees. 

(7)  Mds-ID  -  client  Mode  S  ID  in  hexadecimal. 

(8)  SFN  -  client  surveillance  file  number  in  decimal. 

(9)  T  -  client  report  type  (N=  normal,  C  =  coast,  and  D  =  drop). 

(10)  M  -  client  track  is  mature  (T  =  true,  F  =  false). 

(1 1)  ID  -  intruder  ATCRBS  ID  in  octal  or  Mode  S  ID  in  hexadecimal. 

(12)  SFN  -  intruder  surveillance  file  number  in  decimal. 
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